Possible to empty filecache before upgrade?

upgrade
help

#1

I'm running owncloud on a rpi - that is, a very slow server. All of owncloud's database tables are less than 30MB large, but for oc_filecache, which is 1,5GB. Currently the migration test seems to be working on testing this table, it created a copy oc_oc_filecache_randomcharacters and this copy is growing at about 1MB per minute.

So I wonder: wouldn't it be faster to somehow empty this cache before the upgrade and regenrate it afterwards? Is this possible? Or should I just wait a couple of days until the upgrade is finished?


#2

1,5 GB is very large, how many files do you store in your ownCloud? Just to give you a number, 100 000 files can be about 60 MB.

Which version of ownCloud do you use? Encryption app?

Just cleaning the cache is not a very good idea, you will lose all shares and other information. However, you can start a re-index of files (will add missing files and remove unvalid entries):
sudo -u www-data php /var/www/owncloud/occ files:scan --all


#3

Your numbers sound plausible, there are probably a couple million files in an external storage I use. Counting them just now to check whether my guess is right (this also takes a long time because of slow rpi).

I'm upgrading to the latest owncloud from owncloud's Debian repo and don't use the encryption app, no (thank god - i wouldn't trust it not to lose my data).

Edit: So, yes, around 2,6 million files.


#4

Impressive, your poor little rpi :smile:

If you update, you can skip migration tests. They take a long time, especially copying large dbs (and even more on a rpi):
https://doc.owncloud.org/server/9.0/admin_manual/maintenance/package_upgrade.html#migration-test
Just don't forget to make a full backup before.


#5

x2, that's impressive, I would have never thought such a low powered machine could deliver an acceptable level of performance for hosting millions of files.


#6

Well. performance is not great, but it doesn't degrade too much as the number of files grows.

It's mostly limited by USB 2.0 speeds, all I/O is hooked up to a single port on the SoC... so reading from the USB disk and sending the data out over Ethernet already halves the possible bandwidth from 480Mb/s to 240Mb/s which is 30MB/s. This is the theoretical maximum, in practice I get less.

But it's enough as long as I don't do massive syncing operations - most of the files are available over the web interface (which works fairly fluently) if I need them, I'm only syncing some selected subfolders to a couple of clients.

The calendar and the mail client are actually the things which don't perform well, not the files. And I think that's due to lack of optimizations and will hopefully improve.

The upgrade finished successfully by the way. :slight_smile: (including migration tests, by the time I had asked here they were so far progressed that I didn't abort them)


#7

Yeah USB 2.0 in perfect ideal conditions only delivers ~50% of its theoretical maximum, due to protocol overhead and other inherent inefficiencies of USB. Cutting that in half again for a shared interface, I'd expect no more than ~16 MB/s out of it. Still impressive that such a small machine can run this stuff!