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, and 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 kernel space 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.