xfs
[Top] [All Lists]

Re: reenabling quota after xfs_repair

To: Robert Sander <robert.sander@xxxxxxxxxxxxxxx>
Subject: Re: reenabling quota after xfs_repair
From: Nathan Scott <nathans@xxxxxxx>
Date: Fri, 19 Oct 2001 16:33:34 +1100
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20011019063540.A16377@xxxxxxxxxxxxxxx>; from robert.sander@xxxxxxxxxxxxxxx on Fri, Oct 19, 2001 at 06:35:40AM +0200
References: <robert.sander@xxxxxxxxxxxxxxx> <200110171613.f9HGDhW17816@xxxxxxxxxxxxxxxxxxxx> <20011018112928.B522717@xxxxxxxxxxxxxxxxxxxxxxxx> <20011019063540.A16377@xxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
hi Robert,

On Fri, Oct 19, 2001 at 06:35:40AM +0200, Robert Sander wrote:
> On Thu, Oct 18, 2001 at 11:29:28AM +1100, Nathan Scott wrote:
> > Are you using Debian?  The versioning scheme used there
> > is a bit different - 3.00pre01-15 is fairly recent, but
> > not quite the same as 3.01-final from sourceforge.  I've
> > forwarded Michael's explanation of his numbering scheme,
> > below.  I have successfully used the 3.00pre01-15 Debian
> > package with XFS for quite some time now.
> 
> Me too. And then I did run xfs_repair on that filesystem.
> xfs_repair did not rport anything about quotas, they just
> went away.
> So I did several things.
> First I got the newest quotatools from sourceforge. Did not
> matter (really!).

OK, so we can cross that off the list of potential problems.
Good to know.

> Then I umounted the filesystem, deleted "usrquota" from /etc/fstab
> and mounted it again: no quotas, that's ok.
> Then I umounted the filesystem again, put "usrquota" back into
> /etc/fstab, mounted the filesystem, /var/log/kern.log says:
> 
> Oct 19 06:14:25 raman kernel: Start mounting filesystem: sd(8,17)
> Oct 19 06:14:25 raman kernel: Ending clean XFS mount for filesystem: sd(8,17)
> Oct 19 06:14:25 raman kernel: XFS quotacheck sd(8,17): Please wait.
> Oct 19 06:15:01 raman kernel: XFS quotacheck sd(8,17): Done.
> 

That's looking really good.  So we definately have a kernel
with XFS quota enabled..  good, good.

> I thought: "yes", but:
> 
> raman:/usr/src/quota-tools# mount |grep quota
> /dev/sdb1 on /mnt/raid/0 type xfs (rw,usrquota)
> raman:/usr/src/quota-tools# ./edquota gurubert
> No filesystems with quota detected.

OK - so a quick sanity test on my system suggests that there
isn't something fundamentally wrong in the current user tools
(edquota works fine for me).  I see Michael's new quota package
is now in unstable ... apt-get ... yup, this works fine too
(thanks for the quick packaging work, Michael).


So, the way the quota tools work for XFS is to issue a system
call (quotactl) which asks XFS for the quota status for the
specified filesystem.  edquota asks this for all mounted XFS
filesystems, and then stitches together a table of quota info
from all filesystems for the given user or group.  The error
message you're seeing suggests no filesystems are claiming to
support quota at all.

We could be seeing a problem with the system call getting into
XFS (this would be a kernel problem) - has happened before with
some incorrect patches and one of our initial releases was even
botched this way actually.  Which kernel version are you using
(CVS?, a release kernel?, patch? - which patch)?

One way for you to test out this theory is to:

# cd cmd/xfstests
# make
...
# ls -l src/feature
-rwxr-xr-x    1 fsgqa    ptg         77758 Oct 16 01:34 src/feature
# src/feature -Uv /dev/hda8
# echo $?
0
# src/feature -Uv /dev/hda9
quota type (1) not available
# echo $?
1
# 

So, on my system /dev/hda9 does not hold a filesystem with quota
enabled, but /dev/hda8 does.  How does that look for the devices
which you expect to hold filesystems with quota enabled?  (esp.
for /dev/sdb1).

If "feature" fails, then it seems we are not getting into XFS for
your kernel & we'd need to investigate why exactly... if this is
the case, could you mail me the fs/dquot.c file and fs/quota.c (if
there is one) from your currently running kernel?

thanks.

-- 
Nathan


<Prev in Thread] Current Thread [Next in Thread>