On Mon, Jun 12, 2000 at 12:13:36AM +1000, Robert Elz wrote:
>     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.

Hum not enouth context to remember what we were talking about here :)

> 
>   | 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.

An inode walk is already done in fsck, quotacheck could be done here.
We only need to account for inodes cleared by fsck later.

> 
>   | 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.

Why ?

> 
>   | > 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.

The problem is you don't have any way to init the quota file for MFS (no
quotacheck here !) execpt by using edquota maybe.

> 
>   | 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).

Note that the filesystem is empty for now :)

> 
> 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, at best, requite hacking /etc/rc.d/*
The shutdown can also be done by clueless operators.

> 
>   | 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.

ok. I'll think at this.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--