Subject: Re: revisiting quotas
To: Robert Elz <kre@munnari.OZ.AU>
From: Manuel Bouyer <firstname.lastname@example.org>
Date: 06/11/2000 19:01:03
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 <email@example.com>
> 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.
> | 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.
> 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.
That's why I'd prefer to have a generic solution.
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr