On Mon, Jun 12, 2000 at 02:46:06AM +1000, Robert Elz wrote:
>     Date:        Sun, 11 Jun 2000 16:32:33 +0200
>     From:        Manuel Bouyer <bouyer@antioche.lip6.fr>
>     Message-ID:  <20000611163233.A23305@antioche.lip6.fr>
> 
>   | >   | 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 :)
> 
> That was the "quota clean" bit in the superblock - apologies for taking
> so long to respond to your first message, I was away for a week, then
> took another week to catch up on NetBSD mail to see whether there had
> already been a discussion on all of this.

Ha ok. It was not in the superblock, but in the quota file itself.

> 
>   | An inode walk is already done in fsck, quotacheck could be done here.
> 
> OK.
> 
>   | We only need to account for inodes cleared by fsck later.
> 
> Ugh!   The thought of attempting to patch up quotas using a damaged
> filesys doesn't exactly fill me with joy.

Once fsck has run, the damaged filesystem shouldn't be damaged any more :)

> 
>   | > Sometimes, that [RW mount w/o quota] is wanted.
>   | Why ?
> 
> "Just because"...  There are times that qotas get in the way, and
> rather than spend ages saving the current limits, raising them
> out of the way (for some subset of users perhaps) and then later
> restoring them all again, it is just easier to run with them disabled
> for a few hours, and then quotacheck after.
> 
>   | The problem is you don't have any way to init the quota file for MFS (no
>   | quotacheck here !) execpt by using edquota maybe.
> 
> The NetBSD MFS is just a FFS in disguise isn't it?  quotacheck should
> work just fine. 

No, because quotacheck runs on the raw device which isn't available for mfs.

> Sure the one currently used has "location of quota
> file" knowledge built in, but that's just a minor deficiency of a user
> level tool, which is pretty easy to fix.  Putting that assumption into
> the kernel makes a whole different level of pain.
> 
>   | Note that the filesystem is empty for now :)
> 
> For quotacheck purposes, other than the size of the quota file
> (which is uid range dependant, not fs size) the emptiness or otherwise
> of the filesys makes no difference - the inodes are all there when
> the filesys is created, quotacheck reads exactly the same stuff
> for an empty filesys as it does for a full one (and it will remain
> that way until we get dynamic inode creation, if that ever happens).

Sure, but the update of the quota file doesn't take much time here.

> On an LFS things might be different (I don't know that filesys), but
> I think someone said that there is no quotacheck for LFS yet.

Yes.

> 
> That is, your 2 minutes is not going to grow to 10 minutes or something
> like that once the 50MB is 48MB full (which will probably take about a
> week if your users are like ours...).
> 
>   | This, at best, requite hacking /etc/rc.d/*
> 
> Yes.
> 
>   | The shutdown can also be done by clueless operators.
> 
> Yes - it could require shutdown hacking too.

That's why I'd prefer to have a generic solution.

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