Subject: Re: revisiting quotas
To: Manuel Bouyer <>
From: Robert Elz <kre@munnari.OZ.AU>
List: tech-kern
Date: 06/12/2000 02:46:06
    Date:        Sun, 11 Jun 2000 16:32:33 +0200
    From:        Manuel Bouyer <>
    Message-ID:  <>

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

  | An inode walk is already done in fsck, quotacheck could be done here.


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

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

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/*


  | The shutdown can also be done by clueless operators.

Yes - it could require shutdown hacking too.