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 <bouyer@antioche.lip6.fr>
>     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
> should).
> 
>   | 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
--