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. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
