Bugzilla – Bug 143267
XFS quota accounting wrong
Last modified: 2007-07-08 19:19:56 UTC
We recently upgraded our main server machine (Dell PowerEdge 2600, PERC3/DC RAID controller) from SuSE 9.0 to SuSE 10.0. We did a "New install" formatting /, /var and /usr. Ever since the install the quotas on the user's home directories have gotten increasingly out of touch with reality including negative quotas. We have turned off quota enforcment for the moment since users with negative quotas can not write to the disk nor can they fix the problem. Here's an excerpt from the output from xfs_check on the filesystem: user quota id 2085, have/exp bc -3785/204 user quota id 2088, have/exp bc 41967/41968 user quota id 2089, have/exp bc 147990/148209 user quota id 2090, have/exp bc 294805/293835 ic 8264/8255 There were no other errors other than these quota errors from xfs_check. I ran xfs_repair on the filesystem but xfs_repair does not fix quota errors (according to the man page). This problem persists across reboots. The users home directory is a 146 GB RAID 1 volume. The PERC3/DC controller uses MegaRaid driver. One other volume on this machine has XFS quota enbled and is showing the same problem but to a much lesser extent since the disk gets fairly little use. Please let me know if you need more information.
I haven't been able to reproduce this problem, though I've had a couple of other reports of it. Does the reporter have a reproducible test case that they can recommend? (just the set of steps you take to see the problem). You should be able to do a quotaoff, then a mount with quota options to force a quotacheck during mount (as opposed to using xfs_repair, I mean) - look for a console message - which resets the counters. cheers.
I tried quotaoff and then mounting again with quota turned on. This appeared to fix the problem on my less active filesystem. I can't try this at the moment on the users home directory filesystem. I'll need to schedule some down time before I can try it. Thanks.
I rebooted the server and when it came back up (after quotas had been disabled) it regenerated the quotas and so far everything seems to be OK. At this point I guess I consider the case closed.
Well, hmm - please keep any eye on it in any case, I'm not convinced there isn't an issue lurking here somewhere. We just need to know what triggers things to go astray, thats the tricky part -- so if it happens again, let us know, and any details on what sort of activity was occuring at the time could help. thanks!
Stephan Jansen wrote: --------------------------- We never did see this problem again, or at least I never noticed it. We will be moving to a new server machine running SLES 10 in about a week so I doubt we will see it again. Thanks for looking into this.
As per the previous comment, I am closing this bug since it is relatively old, with no further commentary. Please re-open and update this bug with the appropriate product information if the problem recurs.