[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: the bouyer-quota2 branch
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
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
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
Main Index |
Thread Index |