Date:        Sat, 10 Jun 2000 18:43:01 +0200
    From:        Manuel Bouyer <bouyer@antioche.lip6.fr>
    Message-ID:  <20000610184301.A1121@antioche.eu.org>

  | I did it, it's not much work.

The question is how well it really implements the quota system.

  | It's not necessery but would make things easier ... and saves a filesystem
  | walk :)

Yes, it could save that, at the expense of making fsck that much bigger.
The "filesystem walk" in quotacheck, compared with what fsck does, is
pretty trivial though - without looking it may be that to fit it into
fsck you'd either just add another filesystem (inode) walk inside fsck,
or add enough complication (have I been here before, etc) type tests
that it gets more complex than you need.

  | I though about it as a way to ensure that the quota file is always
  | consistent:

Yes, for that it is needed.

  | one would have to really want to have a FS mounted R/W with quota off.

Sometimes, that is wanted.

  | > That is a little difficult on a MFS filesystem...  (and yes, quotas on
  | > MFS are entirely reasonable).
  | I'm not sure it does work rigth now ...

I haven't tested it on NetBSD, but it would be pretty hard to break
the way the quota stuff was done originally.

  | My system is a NFS server, quotacheck on the 85GB filesystems takes
  | about 2mn

OK, that I consider to be basically reasonable.  A little annoying
perhaps, but certainly within expectations.   I have had quotacheck
take 20mins+ (on a much smaller filesys - it wasn't the filesys scan,
but the quote file update that used all the time).

When dealing with rare shutdowns on systems like that, when you (the
maintainer of the system) know what you're doing it is pretty easy to
arrange for the quotacheck to be skipped.  It is harder to automate
without creating lots more restrictions (like requiring the quota file
to be on the filesystem, and perhaps even with a magic filename).

  | This idea could work, I'll think about it. The problem I can see is how to
  | get back the info if quotacheck needs to be run or not. Another quotactl
  | call ?

Yes, probably, but not a "am I up to date" - that would be kludgy, and
lead to race conditions, rather have a "enable quotas if clean"
quotaon variant, which enables the quotas iff the quota file handed
over is the same one last used for the filesys, and the filesys has that
file marked as up to date - otherwise it fails (EWHATEVER) and
quotaon (or mount perhaps) then runs a quotacheck, and retry.

kre