Bug 143267

Summary:	XFS quota accounting wrong
Product:	[openSUSE] SUSE LINUX 10.0	Reporter:	Stephan Jansen <jansen>
Component:	Basesystem	Assignee:	Forgotten User aHtZ2osk0j <forgotten_aHtZ2osk0j>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Major
Priority:	P5 - None	CC:	nathans, tbullock
Version:	unspecified
Target Milestone:	---
Hardware:	i686
OS:	SuSE Linux 10.0
Whiteboard:
Found By:	Customer	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Stephan Jansen 2006-01-14 15:51:34 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.

Comment 1 Nathan Scott 2006-02-05 21:56:54 UTC

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.

Comment 2 Stephan Jansen 2006-02-06 17:07:19 UTC

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.

Comment 3 Stephan Jansen 2006-02-21 15:01:51 UTC

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.

Comment 4 Nathan Scott 2006-02-21 21:45:18 UTC

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!

Comment 6 Matej Horvath 2007-02-23 13:51:24 UTC

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.

Comment 7 Ted Bullock 2007-07-08 19:19:56 UTC

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.