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

Re: [Acl-Devel] Re: ext3 and acls?



On Tue, Jun 26, 2001 at 02:08:50PM +0200, Andreas Gruenbacher wrote:
> 
> Could you tell me your overall idea?  My patch works by recording which
> blocks are EA blocks in the inode scan phase (pass 1), and then check each
> of these blocks from the lowest to the highest block number (which
> minimizes disk seek times). Since there is no guaranteed correlation
> between inode numbers and EA block locations, if checking each EA block as
> they are found could lead to excessive seek times and disk activity.

There's a similar issue to with indirect blocks, and pass1 has a
framework for dealing with that.  (Basically, after reading the inode
table for each block group, you have to seek anyway, so that's a good
a time as any to deal with all of the inodes with indirect blocks; so
all of the inodes which use indirect blocks are queued until the end
of the block group; also this means that any seeks will tend to be
localed with in the block group, which tends to speed things up.)

Also, if it's the case that a lot of inodes are sharing the same ACL
structure, then we won't have that many extra EA blocks anyway.  So
we'll see.  I'm going to do some timing studies to see what strategy
actually makes that much difference.

(From my experience of doing the indirect block optimizations, trying
to reduce the seek time by batching the indirect blocks until later
provides a small improvement, but it's actually not as great as one
might think.)

As far as the overall plan, basically, I've created a refcount
abstraction which gives me a sparse array of EA block addresses and
reference counts, which can be efficiently accessed and updated.  I
also have a block bitmap which indicates whether a particular EA block
has been checked already.  When we process an inode with an EA block,
we check the EA block bitmap, and if it hasn't been checked yet, we
check it.  We use the sparse refcount abstraction to keep track of how
many times a particular EA block has been seen, to make sure the
refcount is correct.  When the entry in the refcount abstraction is
decremented to zero, it's removed from the refcount abstraction; if
e2fsck finds an inode with an EA where it's set in the EA block
bitmap, but there's no entry in the refcount abstraction, then it
knows that refcount was too long, and it can adjust it.  At the end of
the pass, we check the refcount abstraction to see if there are any
entries left over; if they are, that means that the refcount is too large.

At the moment this check is done inline; although if it turns out to
be a problem, we can do them in batches, just as we do with the
indirect blocks in pass 1.

> My patch for e2fsprogs duplicates some of the bitmap manipulation code to
> check teh sanity of EA blocks. Maybe the bitmap code that is in e2fsprogs
> can eb generalized so that the code doesn't get duplicated.

The bitmode code in the libext2fs can be easily generalized.  There is
a the block bitmap and inode bitmap functions are all based on a
generic bitmap set of functions.  So that's not a problem.

> Good idea. For that you could use a hash table or similar, not too
> different from how it's done in the kernel. I'd guess it's a good idea
> only to enable such behavior only if requested explicitly. Also, some sort
> of policy seems to be necessary: Trying to keep EA blocks close to the
> inode's block groups should improve speed; linking too many inodes to the
> same EA block (say, more than 100 or more than 1000) causes disasters if
> this one disk block becomes damaged for some reason like a medium error.

I'm not all that worried about that last case.  If an ACL entry has
been used 1000+times, then it's likely that it wouldn't be hard to
figure out what the ACL was and how to reconstruct.  (i.e., the
sysadmin will be able to figure it out).  If one disk block getting
damaged destroys the actual file data of 1000 files, I'd more be
concerned, but it's just the ACL information.  I'd suggest that we and
see whether or not it becomes a problem in actual practice; if it is
one possibility would be to use e2image to back up the EA blocks as
part of the filesystem metadata.

					- Ted





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