On Sun, Jun 11, 2000 at 12:54:10AM +1000, Robert Elz wrote:
>     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).

It's not the problem. The problem is that it's a 85GB filesystem.

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

I did it, it's not much work.

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

It's not necessery but would make things easier ... and saves a filesystem
walk :)

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

I though about it as a way to ensure that the quota file is always consistent:
one would have to really want to have a FS mounted R/W with quota off.

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

I'm not sure it does work rigth now ...

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

Exept for MFS :)

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

My system is a NFS server, quotacheck on the 85GB filesystems takes about 2mn
(I have another machine, only 50GB but slower disk system, 2mn also).
Sure I don't expect to take the machine down often but it can happen
(last time it was because of a UPS stupidity), and it's annoying to have
to wait for 2 more minutes after a clean shutdown.


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

This idea could work, I'll think about it. The problem I can see is how to
get back the info if quotacheck needs to be run or not. Another quotactl
call ?

--
Manuel Bouyer <bouyer@antioche.eu.org>
--