On Fri, May 01, 2009 at 08:16:01PM +0200, matthieu castet wrote:
Package: e2fsprogs
Version: 1.41.5-1
Severity: normal
File: /sbin/fsck.ext3
recent version cause a storm of i_file_acl_hi should be zero on a old ext3
partion that I mount readonly.
After some investigation it seems i_file_acl_hi is an ext4 feature : it
is only present in linux-2.6/fs/ext4/ext4.h, but in
linux-2.6/include/linux/ext3_fs.h it is a padding field (i_pad1).
That's correct. The field should have always been all zero's, and it
would be interesting to investigate how they had gotten set to some
non-zero value in the first place.
Older (pre 2.6.30) versions of the kernel will blow up in very
entertaining ways if you try to mount an ext3 filesystem using the
ext4 filesystem code. This is supposed to work, since the ext4 code
is fully backwards compatible and is supposed to mount ext2 and ext4
filesystems. So there is a patch that has gone into 2.6.30-rc4 that
fixes ext4 to not look at that field unless the 64BIT feature is set.
However, in order to make things work better for people using older
code, I also added a fix to e2fsck to detect this condition and offer
to fix it. On an ext3 filesystem, it is harmless, but it's nice to
make fix this problem, which should have never happened under normal
circumstance.
I believe my readonly partition is valid, but wonder why I doesn't get
no error on my read/write partition. May be the ext3 linux driver, did
some modification.
This is quite annoying as it stop the system from botting.
Probably the right thing to do is to mark this type filesystem
corruption as one that can be fixed in preen mode. That way the
filesystems with this should never happen condition will be cleaned
up, but it won't stop users' systems from booting.
Thanks for reporting this issue!
- Ted
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
