Re: fs-independent quotas

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

On Fri, Oct 21, 2011 at 01:40:01PM +0200, Michal Suchanek wrote:
> On 21 October 2011 12:35, Manuel Bouyer <bouyer%antioche.eu.org@localhost> 
> wrote:
> > On Fri, Oct 21, 2011 at 12:03:25PM +0200, Michal Suchanek wrote:
> >> By the same token you can say that the hierarchy starts at type
> >> because block quota is different from file quota and only within the
> >> same quota type the (class,id) pair is unique but that's all grafting
> >> artifical hierarchy to a simple table.
> >
> > OK, you can represent it as a simple table for a given filesystem.
> > But then you may have a different format for different filesystems.
> > With a hierarchical, or multidimensional array representation, you have
> 
> A multidimensional array is in my book a uniform and non-sparse structure.
> 
> That is it has n indexes with the i-th index having the same type
> across all of the array and any combination of n valid indexes
> referencing an actual cell which is of the same type across all of the
> array and always present even if not used by the current operation.
> Then this array like the table is specific to each filesystem.
> 
> Yes, you can emulate something that looks on the surface like an array
> with some kind of dictionary tree which can be non-uniform and sparse
> and whatnot but it's no longer an array.

You're right. What this is is really a tree, not an array.

> 
> The dictionary tree may wrap disparate values and index types across
> filesystems into a single dynamically typed structure but to work with
> the structure you still need to handle the disparate types and
> indexes, they are just hidden inside something else.

For a whole class of filesystems, you'll have the same types and indexes.
It's just that some of the keys may be optionnal.

> 
> When this is represented as a proplib blob transferring the blob
> always succeeds but parsing the blob requires that the application
> parsing the blob be aware of the api version of the blob, same as it
> would need to be aware of api version of the binary table if it was
> transferred unwrapped by the syscall.

I agree. But with a good use or prolib, you can do changes to the format
without requiring an API bump (for example, grow a type from int32
to int64, or add an optionnal key to an array).


> 
> That you can make some sense of the proplib data by looking at it in
> vim is paid by numerous conversion dances in the kernel and userland
> tools. In the end the tools will be broken if the api version does not
> match one way or another, and you can make sense of the binary blob by
> looking in the header where it is described, too.

"numerous" is a strong word here. There are convertions in the kernel that
would happen anyway (you have to convert from the syscall API to the
filesystem API), and I think the userland tools could be doing less convertions
than they're doing now.

> 
> I don't expect that results of a syscall be feed directly to vim on
> regular basis. Indeed, you still have to write some code to perform
> the syscall in the first place so you can as well add a few lines that
> print struct fields.
> 
> > and this makes your table space as sparse as a multidimentionnal array,
> > as not all the type,class,id combination make sense.
> 
> It is not. It assigns values to keys, not all keys need be present in the 
> table.

Nor in the tree-based dictionnary, or in the multidimentionnal array.
What a table can't easily express is that a line of this table can be
of variable lenght, and some of its fields are optionnal.

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