Bug 22234 - ext3 fsck incorrectly reads journal inode on PowerPC
ext3 fsck incorrectly reads journal inode on PowerPC
Product: Red Hat High Availability Server
Classification: Retired
Component: ext3 (Show other bugs)
noarch Linux
medium Severity medium
: ---
: ---
Assigned To: Stephen Tweedie
Wil Harris
Depends On:
  Show dependency treegraph
Reported: 2000-12-13 11:12 EST by jpgarcia
Modified: 2007-04-18 12:30 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-12-13 18:09:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
ext3 byteswap diff for e2fsprogs (553 bytes, patch)
2000-12-13 12:02 EST, Stephen Tweedie
no flags Details | Diff

  None (edit)
Description jpgarcia 2000-12-13 11:12:04 EST
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
kernel space
and user space, or it is reading it and assuming it is ne, when it appears
to be written in le.
Comment 1 Stephen Tweedie 2000-12-13 12:00:30 EST
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.
Comment 2 Stephen Tweedie 2000-12-13 12:02:09 EST
Created attachment 6372 [details]
ext3 byteswap diff for e2fsprogs
Comment 3 jpgarcia 2000-12-13 14:09:45 EST
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.
Comment 4 Stephen Tweedie 2000-12-13 15:18:31 EST
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?
Comment 5 jpgarcia 2000-12-13 18:09:39 EST
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?
Comment 6 Stephen Tweedie 2000-12-14 11:56:11 EST
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.

Note You need to log in before you can comment on or make changes to this bug.