Owncloud calculates wrong used storage for user

[tflidd]

Owncloud shows in the webinterface (and client) that 4.3 GB of 20 GB are used. 20 GB is my maximum quota that is ok, but the 4.3 GB are wrong, it is way to less, only the data are already 14 GB:

du --max-depth=1 -h
216K    ./thumbnails
14M ./gallery
81M ./cache
14M ./lucene_index
25M ./files_encryption
1.8G    ./files_trashbin
987M    ./files_versions
14G ./files
12K ./files_external
24K ./documents
17G .

I tried to get some inspiration from these topics (might be related):
#12744
#5786

Search for -1-sized files on the user's storage

SELECT * FROM filecache WHERE path LIKE 'files/%' AND size = -1

gave an empty result.

I did a query for the user's storage id (home::username):

SELECT SUM( size ) , MIN( size ) FROM filecache WHERE STORAGE = '3'

SUM(size)	MIN(size)
92585711586	0

Some time ago, I found some query for SQL to calculate the storage and it was more or less the value from the "file"-folder in the system.

I have an old updated installation and you changed the storage paths. Now the user's path is home::username, but I also have a storage id with the absolute path

id	numeric_id
home::username	3
local::/var/www/owncloud/data/	57

And for this storage id 57 I can find some entries in the filecache-table with size=-1
for each user and some other entries (there are even more):

fileid	storage	path	path_hash	parent	name	mimetype	mimepart	size
30622	57	username	hashvalue	30604	username	2	1	-1
30604	57	(empty)	hash	(empty)	-1	2	1	-1
30609	57	gallery	hash	30604	gallery	2	1	-1
30610	57	pubShare_a805af4b	hash	30604	pubShare_a805af4b	2	1	-1
30612	57	cache	hash	30604	cache	2	1	-1

During numerous upgrade, I ended up some time with some users having their storage with local::/var/www/owncloud/username and new users with home::username. You told me to change all users to home::username. For other encryption problems I rebuilt the filecache once (I didn't help to correct the quota problems).

It's not urgent as it doesn't produce any problems. I'm only afraid of some strange behavior when I'm hitting the quota limit one day. Is there any guideline how this storages have changed and how they are supposed to look like?

System: Ubuntu 14.04, Apache, MySQL, with encryption, no external storage, OC 7.0.4 (problem exists at least since OC 7.0), several upgrades (since OC 4.5).
Logfiles: Nothing particular to this issue.
Apps: News, Bookmarks, Shorty

[karlitschek]

@PVince81

[tflidd]

I found the database-query I referred to #12386 (comment) :

select path,size from oc_filecache where path='files' and storage in (select numeric_id from oc_storages where id like '%theuserid%');

The result is strange:

path	size
files	14659416823
files	9018776

The first result with 13.65 GB seems to be correct. Some time ago (around the original posting of this command, I only had one output, since then probably the upgrade to OC 7.0.4). Now, I have this second entry with 8.6 MB. But nothing refers to the 4.3 GB that is shown in my interface.

Maybe the similar to #12386 but not fixed at 2.4 GB.

[tflidd]

the second result (8.6 MB) belongs to a second user. like '%theuserid%' was not specific enough.

[PVince81]

Normally the size calculation is triggered when modifying files in the storage (ex: upload), then the size is propagated up to the top directory. The only reason I see why it would have a wrong value is that maybe a PHP timeout occurred while it was computing the folder sizes and didn't reach the parent.

Note that only the files under "files" count in the quota. Metadata (ex: thumbnails, cache) aren't counted nor displayed in the UI. The value you see in the UI should be a direct read of the size of the "files" entry from the DB. If it doesn't match that's strange.
The value is read from here: https://github.com/owncloud/core/blob/master/lib/private/files/cache/homecache.php#L66

You could try adding some debug statemens / log statements to examine the values ?

[tflidd]

I'm not a php developer, so excuse me for my "hello world"-like debugging ;-)
I put some error_log messages in the loop you pointed to

if ($path === '' or $path === '/') {

but while navigating through owncloud or using the client and uploading never gets into this inner loop. So I put something in the outer loop, directly after https://github.com/owncloud/core/blob/master/lib/private/files/cache/homecache.php#L63

                error_log(print_r($data['storage'], TRUE));
                error_log(print_r($path, TRUE));
                error_log(print_r($data['size']/1024/1024, TRUE));

and I get as output:

[18-Feb-2015 11:59:01 UTC] home::username
[18-Feb-2015 11:59:01 UTC] files
[18-Feb-2015 11:59:01 UTC] 13982.076548576

After the upload of a file, this 13982....-value increases about the value of the file. During upload it shows the size of the uploaded file, keyfile and the directories within.

One thing I've observed, for one big folder, the output shows:

[18-Feb-2015 12:01:17 UTC] home::username
[18-Feb-2015 12:01:17 UTC] files/bigfolder
[18-Feb-2015 12:01:17 UTC] 10619.275081635

On my webinterface, it only shows 2.8 GB. On the filesystem it shows (rounded) 11 GB.

Another strange thing (seen from web-interface): in this big folder, there is a subfolder (folder2) of size 8.5 MB it contains a folder with 165 MB!
/bigfolder/subfolder 8.5 MB
/bigfolder/subfolder/folderx 165 MB
from my debugging code, the /bigfolder/subfolder shows the size 176 MB.

Taking this subfolder, I went to the filecache table:
size -> 185111004
encrypted_size -> 8916065

There are the 8.5 MB!

[PVince81]

Okay, so I suspect that the file size calculation has aborted mid-tree at some point.
I'd expect sudo -uwww ./occ files:scan --all to fix that, but I'm not 100% sure it will recalculate the sizes. (@icewind1991 ?)

[tflidd]

@PVince81 I had this problem already on OC 7.0.2/3 and at that time and I did a complete filescan. This didn't help.

[PVince81]

If it's only one folder with the discrepancy, you could try manually updating one of the files to force recalculation. But it might be tedious.

We should look into adding a repair of file sizes when running ./occ files:scan --all. @icewind1991 what do you think ?

[tflidd]

Rescanning makes it probably worse. During rescanning the unencrypted_size is set to 0: #11632

I found a smaller folder with the wrong size. What helped was to create a little textfile in each folder, then the size of the folder gets recalculated (you have to start from lowest level). There were in fact files from before the filescan with unencrypted_size 0 in the database. Now it is showing the right size. By indexing some big folder, the total quota is already at 6.1 GB. 8 GB more to scan through folders, yeah.

Nether the less, on the lowest level there is a size for each folder (always too big). Are these estimates based on the encrypted size? It is corrected after rescanning the folder. Wouldn't it be easier to use the unencrypted size, then the files:scan-process can calculate the correct size? And it's the actual space used by the files.
But I haven't found the reason it got wrong in the first place (intention of the rescan was to get the quota correct).

[PVince81]

The reported size is supposed to be based on the unencrypted_size. If otherwise, might be another bug 😦

[tflidd]

I found another folder for you where all files haven't been touched and have all unencrypted_size=0. Here what I see before:

in the opened folder (why is it different?):

from the database

Then I went into each subfolder, created an empty textfile and deleted it again (same three screenshots):

inside the folder:

and database:

If no unencrypted_size is available, owncloud seems to put the encrypted size in it. But only for some files and it doesn't account for the quota.

[tflidd]

@PVince81 : I did scan all files for this user. Unfortunately it doesn't help. There was even a text file with a missing keyfile. It was a new textfile so I don't know why the keyfile is missing and the file really is encrypted. Luckily this file was not important.

I did a new test with OC 8.0 (fresh install):
Enable encryption, create new user with 20 MB quota, fill up ~20 MB of data, logout.
size/1024/1024: 26.35573292 unencrypted_size/1024/1024: 19.92421341

Then rescan. This time the filecache-table keeps the unencrypted_size-values and there is absolutely no problem (at least with new setups).

Let's suppose the filecache-table is corrupt, so I emptied it and then did a rescan:
size/1024/1024: 26.35573292 unencrypted_size/1024/1024: 0
but the quota in the webinterface shows now 26.xx MB. Then I waited some time and did nothing on the web-interface, suddenly the quota was at 0B! And I could upload even more data:
size/1024/1024: 49.40813160 unencrypted_size/1024/1024: 17.21523952
now I could go through all sub-folders, to update the unencrypted_size-field for all files.

Now I can't even force owncloud to recalculate the folder size as I could do it in OC 7.0.4. E.g folder tt:

I added a small text file, on the bottom line it shows 2.4 MB. If I go one level higher:

This folder is smaller than <1KB! I tried to recreate text file in the "tt"-folder and in the parent folder.

edit: Renaming the files (inside the "tt"-folder) helps to update the unencrypted size folder size of "tt"!

[PVince81]

Hmmm very strange... possibly a problem with the propagator.

I'd expect that any action within a subfolder (especially creating/editing files) would update the folder's sizes.

[PVince81]

There is a problem with the propagator in OC 7 and OC 8 for folders shared from a subsubfolder: #14596

[tflidd]

I see. I use only a few shared folders, most data are in unshared folders. In most cases I only provide a download-link for some files.

I didn't find a way to reproduce my error. You will probably have to go back to OC 5 and start with an encrypted system.

[PVince81]

Are you still seeing this issue in 7.0.7 or 8.0.5 ?

[tflidd]

I disabled encryption and had some minor problems with the unencrypted_size-field (#16742) in 7.0.5. I haven't seen it happen again (OC 7.0.7). I didn't know how to reproduce this error, so I can't verify if it can happen again. Without further input there is not much we can do at this time, perhaps it has been fixed.

From my point of view, we can close this issue and reopen it in case someone still sees this issue.

[PVince81]

Thanks for the feedback.