Re: Quota definitions

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, Jul 21, 2009 at 07:59:20AM +0000, David Holland wrote:
> So it seems the only filesystems we have that support quotas are the
> ufs-based ones. It appears that ufs/ufs/quota.h consists almost
> entirely of more or less fs-independent declarations; however,
> ufs/ufs/ufs_quota.c will not translate to non-ufs fses without a good
> bit of hacking.
> 
> Since I'm planning to unhook lfs from ufs, and it would be desirable
> to retain quota support, I'd like to sort this out.
> 
> There appear to be two basic alternatives: one is to rework
> ufs_quota.c and move it to genfs; the other is to leave ufs_quota.c
> where it is and reimplement or clone the logic for each fs. Clearly
> the first is more desirable, particularly in the long run, but I'm not
> sure how realistic it is.
> 
> In either case the fs-independent parts of ufs/ufs/quota.h probably
> ought to be moved to e.g. sys/quota.h. (Is there any significant
> number of 3rd-party tools that know how to find ufs/ufs/quota.h? I
> wouldn't think so, but one never knows...)
> 
> Does anyone have any thoughts on this?
> 
> (The other question is whether it's advisable to assume that every fs
> should/will have the same on-disk quota format, especially since the
> existing format is not y2038-proof. But maybe it's best not to go
> there just yet.)

I would go with a new format. The current format is a table indexed
by uid or gid. If you use large uid you get a very large sparse file.
A different indexing scheme is needed.

I think FFS quotas needs to be reworked anyway so they're part of the
filesystem metadata (probably as a hidden special file). This way
quotas could be handled by WAPBL and fsck_ffs, without the need of the
extra quotacheck step on boot (it adds 20 to 30 minutes to reboot time on
my NFS server).


-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--