Re: [PATCH 2/2] Large EAs

[Andreas Dilger <adilger@sun.com>]

On Nov 26, 2008  01:54 -0500, Theodore Ts'o wrote:
> It's already the case that if we have an orphaned EA block, we'll lose
> it.  The question is whether it's important to keep a large EA if it
> gets orphaned, especially given that there are already plenty ways
> that we can lose EA's (i.e., ftp, tar, NFSv3, etc.).  So if someone is
> going to store a multi-megabyte EA, and we lose it because the inode
> it was attached to gets destroyed, or the inode gets corrupted to the
> point where we can't find the root of the EA tree --- the question is
> --- will we care?

One benefit I think is that at least the orphaned EA inode can be
cleaned up instead of lingering in the middle of the shared EA tree.

The other issue is that I don't want to give up the e_hash field for
the EA, because that is a useful checksum of the EA contents.

Another benefit of having separate EAs is that it makes it tractable to
modify very large EAs.  Otherwise, if there are a number of large
EAs shared in a single tree they would all have to be modified in order
to store a larger value for an EA in the middle of the tree.

To be honest, I don't think that it is worth a great deal of effort to
optimize this corner case.  I would rather keep the EA structure simple,
and if running out of inodes is a problem we would be far better off to
have a much more widely useful solution like dynamic inode tables instead
of working around that limitation with complex EA code.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.