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
some dimensions that are empty but the final datas can be shared by
all FSes.
> It's not multidimensional array
> at all, it would be very sparse as large portions of the
> multidimensional space are useless.
And how is this a problem ?
>
> 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.
and this makes your table space as sparse as a multidimentionnal array,
as not all the type,class,id combination make sense.
>
> 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.
Yes, but I don't need to create a new syscall, with the versionning
issues this has.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
