Red Hat Bugzilla – Bug 22234
ext3 fsck incorrectly reads journal inode on PowerPC
Last modified: 2007-04-18 12:30:11 EDT
building the fsck.ext3 included ext3-0.0.5c on my powerpc, it found
that the inode for the journal was invalid, removed the journaling flag,
checked the disk. the journal inodes of my two file systems are as follows
12; reported by e2fsck as 201326592 (12 * 2^24)
3353; reported as 420282368
possibly a unnessesary or missed byte swap for bigendian systems between
and user space, or it is reading it and assuming it is ne, when it appears
to be written in le.
The new journal fields are missing from libext2fs's byte swapping function.
I'll attach a patch for that: does it help? I have no bigendian machine to test on.
Created attachment 6372 [details]
ext3 byteswap diff for e2fsprogs
works here. nice and simple. great work.
I did turn a scrap fs into mulch because I checked it when it wasn't cleanly
unmounted. But that's my fault for not reading the docs throughly.
Others worked normally. probably want to add a directive to fsck so it wont
check a dirty system, or at least induce a mount first.
thanks for the prompt response.
No, e2fsck (from 0.0.5c) should be capable of doing filesystem recovery on its
own, so if you experience problems after fscking any ext3 filesystem after a
crash, it's still a bug. Do you have any more details about what happened?
the file system that was not unmounted cleanly, when i fsck'ed it, there were a
lot of inode-clearings, etc. the kind of thing you dont want to see. Now, that
file system has files with changes in permissions, types, and names. Files with
names in tact still do have corruption. it did revert the file system to ext2.
This file system was also encrypted, using the latest cipher patch for 2.2 from
kernel.org, and used the blowfish algorithm.
from the README
>you can now run e2fsck quite happily on the filesystem, but *only as
>long as the filesystem was unmounted cleanly*. If it wasn't, then
>you'll need to get the kernel code to recover the journal from the disk
>by mounting the filesystem (even a readonly mount will cause a journal
Is this what would happen, or does this show something else?
problem with encryption? or is the journal being handled using differing
endian schemes? I recall the inodes were fairly high in value...
any method to test theories?
Read the paragraph above that from the README:
As long as you are using the e2fsprogs from the ext3-0.0.5c release,
e2fsck should work just as expected on both ext2 and ext3 filesystems.
The new e2fsck fully understands the ext3 journal.
If you use an older version of e2fsck from e2fsprogs-1.17 or later, then
you can now run e2fsck quite happily on the filesystem, but *only as
long as the filesystem was unmounted cleanly*.
So if you are running the new e2fsprogs, recovery should work. Only older
e2fsck's without the ext3-0.0.5c support code will fail. Running earlier e2fsck
from e2fsprogs-1.20.WIP development snapshots could be dangerous because they
had an incomplete understanding of the new journal, though.
However, I have no idea if ext3 will work over a crypto loopback. If you can
reproduce this on plain ext3 over a normal block device using the current
e2fsprogs throughout, then please reopen this bug report. Otherwise, there are
too many variables --- older versions of e2fsck, unsupported kernel mods --- for
me to take this much further.
I don't have any big-endian boxes myself, so I encourage you to open another
report if you do give ext3 a chance on a plain block device. There is a new
e2fsprogs being assembled right now which has the obvious superblock
byte-ordering bug fixed, so you might want to wait for that.