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

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



On Sun, 24 Jun 2001, Theodore Tso wrote:

> On Sat, Jun 23, 2001 at 08:43:10PM -0500, Eric Jarman wrote:
> > 
> > If you need acls on ext3 try the set of patches that I've put together.
> > http://www.moldybread.net/patch/kernel-2.2
> 
> Very cool.  I'll download it and give it a try.  Thanks!!
> 
> For people's information, I'm currently working on integrating the
> e2fsprogs EA/ACL patches with e2fsprogs 1.22.  It's actually a bit
> more of rewriting than integrating, since I've figured out a way to
> avoid needing to add another pass to e2fsprogs, and I think it should
> be faster as a result.

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.

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.

Also there are a few non-critical things that could be solved more cleanly
(e.g., the EA feature bit is sometimes not cleared in the same e2fsck run
if bad EA blocks are unlinked).

> I should have a WIP out fairly soon, but I want to do some more
> testing first.  At the moment it doesn't do all of the consistency
> checks inside the EA block itself, but I've gotten the hard part (the
> refcount management) done.  Also left to do is pass1b (where a block
> is claimed both as an EA block and as a data block or part of
> filesystem metadata) handling; and in the future, being able to notice
> when multiple EA blocks contain the same information, and therefore
> can be collapsed together to save disk space.  

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.

Cheers,
Andreas.





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