Re: fs-independent quotas

[Michal Suchanek <hramrach%centrum.cz@localhost>]

On 21 October 2011 15:11, Manuel Bouyer <bouyer%antioche.eu.org@localhost> 
wrote:
> On Fri, Oct 21, 2011 at 01:40:01PM +0200, Michal Suchanek wrote:

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

Except that tools not aware of the new value or wider id will now see
non-unique entries or wrong values due to conversion wrap. I don't
think even this is workable.

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


They will be hidden somewhere inside proplib but they still do exist.
So long as you can assume quota calls are never performance critical
may be ok I guess. Still it adds code bloat and execution time bloat
and and data bloat for no obvious advantage. Conversion and versioning
has to happen one way or another.


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

No, in an array the unused locations do exist.

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

Tables can deal with optional fields just fine. Prior art exists. And
even with optional values they are still way more efficient than XML.

Thanks

Michal