Re: the bouyer-quota2 branch

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

On Mon, Mar 07, 2011 at 01:07:05PM +0100, Manuel Bouyer wrote:
 > > So, I thought one of the points of this was to make the quota
 > > interface fs-independent, but as it seems to have come out all the
 > > pieces and definitions are still in sys/ufs/ufs, and so far at least I
 > > really do not see where to slice to have quota support in a non-ufs
 > > filesystem.
 > > 
 > > Can you explain how this is supposed to be done? And can we move the
 > > fs-independent and vfs-level declarations to sys/quota.h and add
 > > kern/vfs_quota.c for the fs-independent code?
 > 
 > This is one of the things I'm not completely happy with, but it's only
 > a matter of where struct definitions lives, and how to avoid duplicate
 > structures and utility functions.

Is it? At the moment it looks far from clear to me, so if you could
sort it out it would help a lot.

 > struct quota2_entry (and so struct quota2_val) is used for both
 > on-disk storage, and in-memory representation in tools and kernel.
 > I agree this should be split; with an extra level of conversion
 > (between in-memory and on-disk representation). The issue is struct
 > quota2_val: I don't see any reason to have a different structure
 > for on-disk and in-memory represenation at this level.

Well... for one thing N_QL isn't necessarily 2; also the in-memory
representation shouldn't have disk addresses in it (e.g. q2e_next),
and in the syscall interface the types should be logical types, like
uid_t, not sized types. Also the structures in quota2.h are too
hierarchical; a single entry should be an id type (user or group,
maybe others), an id number, a quota type (block, inode, or other
things; SGI xfs has three types), the hard and soft limits and
configured grace period, and the current usage and current expiration
time. (Maybe the configured limits and current state should be
separate structures though. And maybe the id information should be
structured to allow ranges.)

But at a minimum it's like struct dirent; it's not particularly
different from the FFS on-disk structure, but it needs to be its own
thing because it plays a different role.

Currently it looks like any fs that wants to implement quotas has to
cut and paste quota2_prop.c. Surely the proplib gunk can be decoded
fs-independently?

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