Re: the bouyer-quota2 branch

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

On Thu, Mar 10, 2011 at 06:00:06PM +0000, David Holland wrote:
> On Wed, Mar 09, 2011 at 08:20:00PM +0100, Manuel Bouyer wrote:
>  > 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
> 
> That should be fixed in favor of something more flexible before the
> API gets cast in stone; as I was saying there's at least one piece of
> prior art out there with three types of quotas. It isn't clear to me
> that we'll ever care, but on the other hand the cost of not compiling
> in the quota types isn't very high.

It's easy to add more types from the interface POV: just add the strings
to the arrray init and bump N_QL. FSes that don't care will just ignore
it.
Of course the display in the quota tools will have to be completely redesigned
then ...

> 
> Especially since if the interface is really going to be proplib-based
> they can just be arbitrary names.

the userland and kernel have to agree on the names; that's why there are
defined in a common .h

> 
>  > > 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 :)
> 
> that doesn't exactly make any difference...

it makes in the sense that problib knows about the sized types, not the
logical types.

> 
>  > struct quota2_entry isn't the real problem (it's not used much outside of
>  > filesystem), struct quota2_val is.
> 
> Sure.
> 
>  > > 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.
> 
> Well, yes, one of the problems with proplib is that it encourages
> hierarchical structuring of things that should be relations.

I can't see why it's a problem, isn't structuring data a good thing ?

> 
> ISTM that a bundle of quota records should be a single array of
> tuples of the form I described above... at least in the canonical
> format for communicating among system components.

I guess that would make the parser for both userland tools and kernel more
complex, for no real benefit. The hierarchy in the proplib description in
also the hierarchy of how things are parsed in the kernel.


> 
>  > > (Maybe the configured limits and current state should be
>  > > separate structures though
>  > 
>  > I'm not sure.
> 
> I tend to think so because it allows separating the policy (which
> might be independent of a given ID) from the operational statistics
> (which can't be).
> 
>  > > 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.
> 
> If I have 80,000 accounts of which 40,000 are undergrads with the same
> quota policy, it certainly makes sense to pass this to the kernel
> (and, where possible, store it) as one record rather than replicating
> it 40,000 times.

I see. In fact you want quotas for a group of ids, not for a single id.
This is a major design change.

> 
> I agree we shouldn't go off half-cocked and if we're going to set up a
> policy language for quotas it should be designed with some care.
> However, with the default stuff we're already moving in that direction
> so it seems like a logical step.

The default stuff isn't that much of a change from the previous
quota: there also was a default, but it was fixed to unlimited while
now this is configurable. But note that a id never uses the default
limits (in the sense that the usage is checked against default limits),
the default are used to initialise the limits for a entry.

> 
>  > > 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.
> 
> We're talking about like a dozen lines of code, far less than the
> proplist decoding that has to be replicated in every FS.

Yes, I agree it's not too big.

> 
>  > > 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.
> 
> If quota2_val and friends can really be an fs-independent interface,
> then I don't see that there's any value to passing the proplib bundle
> to the FS.

Because the proplib string also contains the commands, and they
may be different between subsystems (they are already: commands are not
interpreted the same way between quota1 and quota2, and some are
quota1-specific).

> If they can't... then the data structures should be
> strengthened.
> 
> Since we are not going to replicate the userland quota tools for every
> different FS type that has quotas, the interface *they* talk has to be
> FS-independent.

there are already differences in the quota tools for quota1 and
quota2; I can't see how these could be hidden from the tools as the
subsystem offers different functionalities. If a filesystem offers a
different set of functionalities, this will have to be handled
by the tools, whatever interface we offer.

> 
> Even if there's some reason it needs to be proplib-based it's still a
> proplib encoding of some physical data structure, and (especially in

dataS structureS (there are several, depending on the command)

> the absence of any kind of proplib schemas) it would be helpful to
> have that structure clearly defined somewhere.

I'm not sure what you call a "proplib schemas", but there is some
description in quotactl(2).

I'll look at extract some functions from ufs/ufs this week-end.

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