Date:        Sun, 28 May 2000 12:47:23 +0200
    From:        Manuel Bouyer <bouyer@antioche.lip6.fr>
    Message-ID:  <20000528124723.A210@antioche.eu.org>

  | I'm not happy with the way quota works currently: even after a clean reboot
  | quotacheck is run, which can take some time on a big filesystem.

Make sure you're not suffering from quotacheck stupidity and a large
quota file (a valid, or invalid, large uid leaving a hole in the quota
file can make quotacheck very slow .. even on a big filesys, just reading
the inodes shouldn't take very long).

  | My first though was to add a flag similar to the FFS clean flag,

This might be possible, but not at all easy I think.

  | This sheme works fine most of the time, but the fact that mount and quota
  | are separate can lead to inconsistencies:

Combining them can't help (not in the general case) there are always going
to be circumstances where you want a filesys mounted without quotas
enabled, even if they normally would be.   So the system has to be able
to cope with that.

  | quotacheck can be integrated to fsck,

I don't think this is a good idea, I also suspect it is unnecessary.

  | and quotaon can happen at mount time

That is reasonable, mount does so much anyway...

  | (this can be controlled with tunefs for example).

But I doubt that is the right way, just a mount opt (in fstab, or
on the cmd line) seems better.

  | The counterpart is that we can't have the quota file in an arbitrary
  | place, but I don't think it's a real problem: the quota file can live
  | in the filesystem itself,

That is a little difficult on a MFS filesystem...  (and yes, quotas on
MFS are entirely reasonable).  The usage data isn't a problem (it is kind
of certain to be all 0's when the MFS is created), but the limits, etc,
all need to be fetched from somewhere.

I guess there might be an argument for splitting the quota file, putting
the usage info in a file that must be on the filesys, and the rest of
it on a file that could be anywhere, but I suspect that doesn't gain
anything much worth having.

How much of a problem is there really to solve here?   I assume that a
system that has quotas has real users on it - and consequently isn't a
system that is being rebooted during development every half hour or
so (and so shaving seconds off boot time can really help).

If you were to do something like this, the way to go would probably be to
stick the dev/inode# of the current "correct" quota file in the
superblock somewhere, if the system alters usages anywhere that gets
cleared.   When the filesys is unmounted, if quotas were enabled and
updated, the file's details are put there.  When quotas are to be enabled
if the file to be used has its details in the superblock, skip the
quotacheck.

This wouldn't be foolproof, but it would mostly err on the side of
safety (if a filesys changes its dev due to device renumbering,
quotacheck gets run, perhaps unnecessarily - you'd be real unlucky to
have another filesys take the old dev, have a quote file on it with the
same inum, and you just happen to decide to switch to that quota file,
all at the same time...)

kre