Re: Quota definitions

[David Holland <dholland-tech%netbsd.org@localhost>]

On Tue, Jul 28, 2009 at 08:53:41PM +0200, Manuel Bouyer wrote:
 > > > 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'm not convinced. Linux did this and I don't really see the point -
 > > instead of reusing the FS's tree structure for managing a sparse file,
 > > they added another layer of tree structure, which buys complexity and
 > > recovery problems and not a whole lot else.
 > 
 > This huge sparse file cause issues too; some tools don't deal properly
 > with sparse files. Now, if the file is hidden most of these issues go away.

Such tools should be fixed :-)

Of course, in any new implementation the quota file should be hidden,
but I think we ought to keep the existing FFS quota representation for
FFS to retain interoperability.

 > > Because uids mostly tend to come in contiguous sequences, I'm not
 > > convinced that in practice one will tend to see quota files with lots
 > > of blocks that each hold the info for one user and are otherwise
 > > empty. Except maybe on large installations with lots of uids and lots
 > > of uid turnover, but even then I expect a much bigger problem is that
 > > quota records for removed users probably aren't ever G/C'd.
 > 
 > Yes, that's another issue. The uid turnover also leads to a sparse uid
 > map.

Right. Changing the data structures around won't help much with that
though.

-- 
David A. Holland
dholland%netbsd.org@localhost