Re: Quota definitions

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

On Tue, Jul 21, 2009 at 03:02:00PM +0300, Antti Kantee wrote:
 > On Tue Jul 21 2009 at 07:59:20 +0000, David Holland wrote:
 > > [quotas]
 > 
 > The problem I saw with quota a while ago when I was looking into it was
 > the quota vfsop interface definition.  Since "arg" passed to quotactl is
 > a void pointer and interpreted by the file system instead of a generic
 > layer, we cannot have a quotactl utility which does not know about the
 > file system for which it controls the quota... well, unless we assume
 > that all file systems use the same control structures as ufs.

The problem is deeper than that; because the quota files themselves
are more or less part of the ABI (e.g. edquota falls back to writing
them if it can't quotactl()), without a complete rewrite the whole
thing assumes all filesystems use the same on-disk quota structures.

And it appears that while ext2/ext3 used to use the same quota
structure as ffs, they've since moved to a different tree-based
format, that's apparently also used on reiserfs. Meanwhile SGI XFS has
something else entirely, that appears to involve counting "realtime
blocks" as well as ordinary blocks. (What if anything does zfs use?)

So it looks like we'd better do that complete rewrite sometime.

 > So while it is not completely unreasonable to assume that lfs would use
 > the same quota control structures as ffs, genfs is the wrong place without
 > further work.  And if you do further work, you might as well re-define
 > the quota protocol and use proplib while you're at it.  Then again, it's
 > hard to generalize from one example and I assume that is why quotas are
 > they way they are.  But, "how hard can it be?".

I'm not clear on what proplib would buy for this. :-p

Anyhow, I'll look into it, sometime...

 > IMHO quota is not the killer application anyone has in mind for lfs
 > and personally I'd not prioritize it very high.  In fact, I'd not worry
 > about supporting quota on lfs at all for the time being.

Sure, but I don't see that there's any point in gratuitously breaking
it either.

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