[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Extended Attributes and Access Control Lists

On Tue, 30 Oct 2001, Andreas Dilger wrote:

> When Andreas G. and I were discussing shared EA data a long time ago
> (I will have to dig it out and re-read my arguments, also on acl-devel
> mailing list) I was advocating something like this also.  At the time
> I was worried about snapfs snapshot data, which is pretty much always
> going to be unique for each inode.
> I believe it went something like (when adding a new EA, or changing an
> existing EA, exit when one of the conditions is true):
> 1)try to find an existing EA with the same header hash value (of the
>   current EA data + new EA data), if so share entire block
> 2)if the current EA block is shared, and we are adding a new EA, add a
>   new EA block with only this entry, and make an "EA block pointer" to
>   the common EA block
> 3)if the current EA block is shared, and we are changing an EA, try to
>   find an EA block with only the other entries, if so do (2)
> 5)if the current EA block is unshared, and we cannot find any matching
>   entries, create a unique EA block.
> The important change is the use of EA "pointers", which allow you to
> have a 2-stage EA entry for a given inode.  At the time we discussed
> this (probably still true now), it was possible to chain EA blocks
> so that we have:
> inodeA->EA1->EA2
> inodeB->EA2
> inodeC->EA3->EA2
> Which means if we have some inode-specific EA data, and some common EA
> data, we can share the common stuff, but hold unique stuff separately.
> The real tradeoff comes whether we will normally need EA larger than a
> single disk block per inode.  If this is common (I don't know the
> expected sizes of the EA attributes you refer to above, Ted) then we
> will save space by sharing the common EA blocks.  If the average size
> is <= one disk block, then this is false sharing, since we will always
> need one EA block for the inode-unique data, so we may as well store
> the "shared" (common) EA data there as well and avoid an extra I/O.
> Andreas G. does the current EA implementation allow "indirect" EA
> blocks, or is it limited to at most a single EA block per inode?

The current implementation allows at most a single EA block per inode.
This has not been a problem so far at all. If it should become a problem,
one way to go beyond this limit would be to store the EA names on this
first block, and to store large values on additional blocks (or even in a
regular file). Although there would be some issues to be solved this seems


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]