Subject: Re: revisiting quotas
To: Robert Elz <kre@munnari.OZ.AU>
From: Manuel Bouyer <firstname.lastname@example.org>
Date: 06/12/2000 15:09:27
On Mon, Jun 12, 2000 at 09:29:26PM +1000, Robert Elz wrote:
> Date: Sun, 11 Jun 2000 19:01:03 +0200
> From: Manuel Bouyer <email@example.com>
> Message-ID: <20000611190103.A268@antioche.lip6.fr>
> | Ha ok. It was not in the superblock, but in the quota file itself.
> That must make it even harder, as the quota file can't tell if the
> filesystem has been altered - quota files can even be dumped, and
> restored years later...
Yes, that's why I'm not really happy with this solution :)
> | No, because quotacheck runs on the raw device which isn't available for mfs.
> quotacheck only uses the raw device for speed (avoiding the extra
> layer of buffering). It will read exactly the same data through the
> block device (on any filesys).
There's no block device either for MFS. Quotacheck ony runs for filesystems
marked 'ffs' in fstab (or mounted type ffs) and need a device.
> (Aside: mfs ought to be able to have a raw device as well, and probably
> | Sure, but the update of the quota file doesn't take much time here.
> No, if you don't have many users owning files (and even more so if
> no updating is actually needed). If you have 30K users, and their
> usages are all out of date (incorrect) the quota file update will
> take longer than the scan on almost any sized filesystem I can imagine.
> (Partly because to allow for the possibility that quotacheck is being
> run when quotas are enabled already, a quotactl sys call is done for
> every correction).
I'm not sure it's safe to run quotacheck with quota enabled, but I
tried writing to the file system while quotacheck was running, this
resulted in a panic :(
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr