On Friday 21 January 2005 00:05, Andreas Dilger wrote:
> [...]
> But as your patch stands it doesn't ever check if i_extra_isize is valid
> for the root or lost+found inode. It just always sets i_extra_isize = 0
(that's the in-memory i_extra_isize)
> and never uses it. Given that the root inode is fairly high-traffic it
> makes sense to use the faster EA space if it is available.
It's only a single block we're talking about, not all the overhead you run
into with huge amounts of attributes in many xattr disk blocks. It sure would
be much cleaner to use the root inode's in-inode space like with all other
inodes, but performance wise I don't think it matters.
> If these inodes have a BAD i_extra_isize it is OK to skip it, but I'm
> not so keen to have an ext3_error() there. If the user doesn't have an
> e2fsck with ea-in-inode support there isn't anything they can do to fix
> it and they will get a full e2fsck on each boot.
Agreed, that would be really bad. We should get e2fsck fixed ASAP.
> Even so, for the effort of setting i_extra_isize = 4 (or larger if we
> initialize the fixed fields) we can do the equivalent of what e2fsck will
> do when it finds a bogus value.
We cannot ask the user, and we don't have the kind of global view that e2fsck
has. Something different may be messed up, and may have lead to the
corruption. It's unlikely, but not impossible.
Cheers,
--
Andreas Gruenbacher <[EMAIL PROTECTED]>
SUSE Labs, SUSE LINUX PRODUCTS GMBH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
