e2fsprogs-1.39-tyt3 and ext4 question

e2fsprogs-1.39-tyt3 and ext4 question

[Zephiris]

I've searched the lists and only saw a previous reference to possibly
harmless 'make check' failures on this version, so I'll just ask.
I've been trying to get ext4 running for some time,  but it appears to be
working normally lately. e4defrag and mballoc patches also appear to be
working fine (everything against 2.6.22.1). But that version of e2fsprogs
(1.39-tyt3), even with the last round of patches against it, appears to
generate many bogus errors when checking the filesystem with 'fsck -fn'.
While using 'data=journal' and other things should reduce the chance of
needing a fsck, it makes me worried.

Is there anything at current that can get around this all, or verify that
the errors it's coming up with are indeed bogus (they certainly look it,
hundreds of errors at block 0 or -1, for instance)?

For previous attempts at ext4, running that version of e2fsprogs would come
up with legitimate looking errors, then 'fix' it. But even rebooting
immediately afterwards into emergency read-only mode would generate the
same errors again. Multiple attempts to fix the errors (with probable
legitimate corruption on a few files from a bad attempt at getting e4defrag
working) effectively just shredded the filesystem. 

Ext4 is appearing rather stable right now, which is also making me think
it's fsck's fault.

Re: e2fsprogs-1.39-tyt3 and ext4 question

[Theodore Tso]

On Thu, Jul 19, 2007 at 03:55:10AM -0700, Zephiris wrote:
> I've searched the lists and only saw a previous reference to possibly
> harmless 'make check' failures on this version, so I'll just ask.
> I've been trying to get ext4 running for some time,  but it appears to be
> working normally lately. e4defrag and mballoc patches also appear to be
> working fine (everything against 2.6.22.1). But that version of e2fsprogs
> (1.39-tyt3), even with the last round of patches against it, appears to
> generate many bogus errors when checking the filesystem with 'fsck -fn'.
> While using 'data=journal' and other things should reduce the chance of
> needing a fsck, it makes me worried.

Can you send me a copy of dumpe2fs and the output of e2fsck -fn?  Yes,
e2fsprogs is running a bit behind the ext4 kernel at the moment due to
me being really busy, combined with the focus of transitioning
e2fsprogs to use git and getting a large number of changes to mainline
after the 2.6.22 merge window opened.

Also can you tell me what set of patches you used against 2.6.22.1?
Was it just the e4defrag and mballoc patches? 

This is the first report I've had that there were issues with the
e2fsprogs 1.39-tyt3 (which I've always said was for developers only),
but I'll look into it and see what I can do.

I do know that a last minute change we made to the extent format just
before the 2.6.23 push to allow 2**15 length extents is not reflected
in the 1.39-tyt3 e2fsprogs.  But the description of the errors you
reported don't sound like that would be the issue.  (And that change
would't show up in real life without some additional patches to
relocate the block group metadata that are definitely not yet in
mainline.)

						- Ted