Re: the bouyer-quota2 branch

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

On Wed, Mar 09, 2011 at 06:28:11PM +0000, David Holland wrote:
>  > 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;

The tools rely on N_QL being defined and constant for all FS types at
this time. The string for each QL is also defined here

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

Sure (although in the syscall interface, all of this are strings now :)
struct quota2_entry isn't the real problem (it's not used much outside of
filesystem), struct quota2_val is.

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

The hierarchy in quota2.h reflects the proplib structure. A proplib quota entry
has a type, and an associated array of entries. Each entry has an id (uid or
gid depending on the type above) and array of values for this id. 
Each value has a type, current usage, limits and grace times.

> (Maybe the configured limits and current state should be
> separate structures though

I'm not sure.

> And maybe the id information should be
> structured to allow ranges.)

I'm not sure we should allow too much at this level. The tools can
allow range if we want, but they should convert it to a list of discrete
entries. don't do too much in the kernel.

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

I agree. What I don't get is how to split it to avoid too much extra
code which would just be a non-optimised memcpy.

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

Parts of quota2_prop.c can, I guess. For the part in ufs_quota.c,
I'm not sure.

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