Subject: Re: bin/23725: possible quotacheck enhancement
To: NetBSD GNATS submissions and followups <gnats-bugs@gnats.netbsd.org>
From: Robert Elz <kre@munnari.OZ.AU>
List: netbsd-bugs
Date: 12/18/2003 23:34:13
    Date:        Wed, 17 Dec 2003 17:37:23 -0500 (EST)
    From:        "Greg A. Woods" <woods@weird.com>
    Message-ID:  <m1AWkIF-0003QZC@proven.weird.com>


  | (I think repquota could also use a similar fix, though it does
  | eventually finish running.)

It looks like it may still have the infinite loop on id==LONG_MAX bug
in there (assuming that id actually gets into the quota file), but
aside from that, there isn't much that can be done to speed up repquota
really - you don't want it to skip reporting users just because they're
not in the passwd file (or groups & group file) - and that's just about
the only real optimisation that can be done.

repquota really has to read the whole quota file (a "read skipping holes"
syscall would help it...) to report what is there, reading that giant
file is simply going to take time, even if the giant is mostly just
a shell around a lot of empty space.

  | There is another bug somewhere, perhaps in the checkfstab() subroutine
  | borrowed from fsck, or in the way it's used.

Yes, this looks to have been broken in 1996.   The code that's there now
is a mess.   I'll look into fixing this during the next couple of weeks
if I can find the time - but given it has been like this now for more than
7 years, and there doesn't seem to have been a huge number of complaints,
I doubt a few more weeks is going to hurt.

Just shoving in exit() is, I suspect, almost the right solution, but
it isn't going to be quite that simple.   What's more, to do things
properly, the preen code in fsck is going to need some changes too
(it is legal to have quotas on a passno==1 filesystem in fstab, but
there's no rational reason for treating those ones any different from
passno==N for N!=1 for quotacheck purposes).

That, or perhaps better, quotacheck and fsck could just agree to go
their separate ways, and end that wacky file sharing/stealing stuff.

  | Turning off quotas, removing the quota.user files, and
  | re-running quotacheck, "fixed" it (even with '-q'), provided I do one
  | filesystem at a time by hand.

The -q there is irrelevant - if the quota file is removed, -q does
nothing - its sole purpose is to avoid reading lots of (your) huge quota
files when almost everything out there is going to be hole.   If the
quota file is removed, or emptied, before quotacheck is run, then there
is nothing for -q to avoid doing.   Where it fails to correct, is where
a user that owns no files, and isn't in the passwd file, is recorded in
the quota file as having a non-zero usage.   Clearly if there is no
quota file, that can't happen...

kre