Re: fs-independent quotas

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

On 21 October 2011 11:31, Manuel Bouyer <bouyer%antioche.eu.org@localhost> 
wrote:
> On Fri, Oct 21, 2011 at 11:14:12AM +0200, Michal Suchanek wrote:
>> >
>> > OK, so let's call it hierachical tablular if you want.
>> > You have different quota class (currenly user, group)
>> > for each class, there are ids (either uid or gid)
>> > for each id, the are quota types (block or file currently)
>> > these quota type have values (limits, usage, times).
>> > This could be represented in a mutidimentionnal array, but a table is not
>> > a complete representation of this.
>>
>> Where is the hierarchy?
>>
>> You have a table indexed by
>>
>> (user|group) id (block|file)
>>
>> which stores
>>
>> limits, usage, time (probably grace time left or time the soft quota
>> was overflowed)
>>
>> Each of the records is completely independent of of each other record.
>> There is no hierarchy whatsoever.
>
> no they're not. block and file records are linked together by the id.
> two id of the same class are linked together in the sense they're
> unique in the class. But the id from one class is not the same thing
> as the id in another. You can also view this as a multidientionnal array.
> A multidientionnal array can be represented as a vector, if the size in
> all directions is known and fixed. If it's not you can't represent it
> as a vector.


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. It's not multidimensional array
at all, it would be very sparse as large portions of the
multidimensional space are useless.

You have a relation here where type,class,id is assigned some quota
values. Of course the id itself is not unique, only type,class,and id
are complete key together.

You assume that in the future a filesystem will emerge that will have
new ID type which won't be covered with a 64bit integer.

That's fine. it will return its quota in a specific format and when
you talk to that FS you will need to know that the records come in
different format. proplib does not solve that for you, it just encodes
the record in a XML blob which you have to parse with the knowledge
what record the blob contains so in the end you will need to adapt to
this new fs one way or another.

Alternatively, you could convert those new IDs to some mount-specific
64bit IDs by some other call to the FS, whatever makes talking to it
easier.

Thanks

Michal