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

Re: Extended Attributes and Access Control Lists

On Tue, Oct 30, 2001 at 08:08:05PM -0700, Andreas Dilger wrote:
> Sounds OK to me, but this would "save" us only a few bytes per EA at
> most.  Given that we only allocate full disk blocks to EA storage, it
> will at most allow us to store a few more bytes in the EA data.  If
> it means we don't have to parse the on-disk EA name for each transaction,
> it may be more worthwhile to make this change.

Yes, but "saving" a few bytes per EA is important if you're trying to
cram variable EA into the inode.....

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

Most of the time, the inode-unique data is going to be fairly small
--- well under a single block, in fact, I wouldn't be surprised if in
the common case the inode-specific data will fit in 256 bytes; that's
one of the reasons why I've suggested storing the EA (or at least part
of the EA) in the inode itself (of course, this requires that we
change the inode format so that there's space for this sort of thing).

> 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 EA format has room for a linked-list of EA blocks,
although I don't believe the EA implementation will deal with more
than one EA block.  (Its's definite that the EA support in e2fsprogs
won't support multiple EA blocks per inode.)

						- Ted

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