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

Re: Extended Attributes and Access Control Lists

On Wed, 31 Oct 2001, Theodore Tso wrote:

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

To give you some numbers:

An ACL plus default ACL for two additional users/groups currently requires
112 bytes on an EA block including all overheads; the ACL data alone is 64
bytes. In an inode most of the EA overheads wouldn't be necessary.

More compact EA/ACL formats would be possible, but would add complexity
and reduce future extensibility.

I am also using EA's for storing author/title/track number/etc.
information for a set of MP3's. On average that takes 100 bytes of raw
data per file.


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