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

Re: Extended Attributes and Access Control Lists


On Thu, Nov 01, 2001 at 01:22:33PM +0100, Andreas Gruenbacher wrote:
> The current implementation allows at most a single EA block per inode.
> This has not been a problem so far at all.

The problem is the lack of space efficiency with many different EAs
present.  ACLs are a special case where we get a lot of repeated EAs
between files leading to good sharing, but in the more general case,
you can't assume that the sharing will work that well.

One thing Ted and I observed was that we already have a solution to a
similar problem: Daniel's tail-merging code.

If we can adapt tail-merging to deal with EAs, then the problem

Once you start thinking about that, two new strategies become
possible: you can have a single tail-handling mechanism dedicated to
EAs and just store the file's data tail in one of the EAs, or you can
do it the other way round and treat the attribute set as a stream with
a tail just like the file data, and have generic tail handling code
for both EAs and data.  

The former mechanism is probably better: if we extend the inode size,
then the extra attribute space made available at the end of the inode
becomes easily used both for tails and for other attributes.

Which then brings up an even more interesting thought: if the
attribute handling is able to use both tail-merging and inode space to
store the attributes, we don't need larger inodes to encode EAs.
But, we *can* encode the larger inode in an EA itself!  If we want to
free up space for fixed fields in the larger inode, for things like
nanosecond-resolution timestamps and security MAC labels, then that
information can be allocated statically as fields in the V2 inode,
but can also be encoded as a V2 EA for existing V1 filesystems if we
want to apply those fields incrementally.

This obviously gets messy, and a static e2resize-type program for
expanding the inodes is much easier, but it *is* possible to migrate
dynamically (and it should even be possible to maintain some level of
backwards compatibility for mounting the new v2-enhanced filesystem on
old ext2 kernels.)


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