Hide Forgot
in quota_unlink_cbk, space_freed is defined as int. so if the file deleted is la rger than 2G, it becomes a negative number and then converted to a very large unsigned long (size_t) number in gf_quota_usage_subtract, which is larger than current_disk_usage, so current_disk_usage is set to 0. also in other callbacks in quota.c
Created attachment 254 [details] /proc/cpuinfo of affected machine...
sorry, this is not the only problem, and the previous patch is not enough. For example, in quota_truncate_cbk, if size of file "/dfs/abcd" is 1024, we run "> /dfs/abcd", it will be truncated to zero first. then space_freed will be (0 - 1024) * 512 = -524288, when calling gf_quota_usage_subtract, the 2nd param will be converted to an unsigned long with value 18446744073709027328 (0xfffffffffff80000), which will cause disk usage reset to 0. And in quota_unlink_cbk, if we unlink a file with size 0, the blocks of its parent directory used may become smaller. Then space_freed = 0 + (0 - 8) * 512, the same problem as above, and the disk usage will be reset to 0.
Created attachment 256 [details] rpm -qa of machine affected
Sorry, please ignore my patch. It did fix some problems, but not enough, too. and it brought in two new problems. After these modifies, we found sometimes the usage is still not calculated correctly. it's not easy to resolve this problem completely. So we get disk usage frequently by calling du. Maybe this feature should be redesigned.
Also if you delete a file over 4g, the space available is only reduced by the amount over 4g. Obviously this is also due to the size_t overflow.
quota is not being supported in 3.1.0 version, we will get the support post 3.1, hence moving severity.
All the quota related bugs moved to one bug for now, as we may have new code for quota *** This bug has been marked as a duplicate of bug 1243 ***