Bug 227670

Thomas, I'm not sure offhand...

Can you point debugfs at the filesystem, probably with the "-c" option, so that
it doesn't have to read all of your inode bitmaps, and run both the "stats"
command (for overall fs geometry) and the "stat <7>" command (to dump the resize
inode), and attach that output?  From that hopefully I can see what is causing
e2fsck to decide that it's invalid, and hopefully identify the patch that fixed it.

Also, does fsck say anything about the resize inode when it's running?

Thanks,

-Eric

Sorry, I submitted that bug three months ago and have since remade the
filesystem as it seemed the only solution. Too bad you didn't reply a day
sooner. I just recently had another filesystem have the same problem but rebuilt
it yesterday morning. Next time it happens, I'll try those debug steps you
suggested.

The fsck says it recreates the inode. See #1.

Thomas, thanks.  If you hit it again, please let me know.

Apologies for the late reply, I only recently got ownership of e2fsprogs, so I'm
going through & triaging the open bugs.

Do you have any idea if there were any "interesting" events that led to the 2nd
filesystem problem?  Also, what exact version of e2fsprogs rpm is this on, just
for the record?

Thanks,

-Eric

I believe it was much the same. It's a hardware RAID device and it reported a
bad disk. The disk was replaced, the RAID rebuilt itself. It's a 24 disk RAID6
array so one disk going bad should in theory not be a problem. It has an ext3
file system with dir_index turned on.

bird> rpm -q e2fsprogs
e2fsprogs-1.35-12.4.EL4.x86_64
e2fsprogs-1.35-12.4.EL4.i386
bird> 

Ok, from an image provided I can reproduce the inability to fix the resize inode
with rhel4's fsck.  Upstream fsck works, so I'll find the fix & bring it back.

-Eric

seems fixed in e2fsprogs-1.38 and beyond.

-Eric

This mod fixed it:
http://thunk.org/hg/e2fsprogs/?rev/4e4a68eff16f

(note that none of this has to do with whatever caused the original corruption,
but at least fsck needs to be able to properly clean it up as best it can).

Created attachment 160773 [details]
backport of upstream patch

This patch at least gets it to the point where the filesystem is mountable
post-fsck.

Built latest rhel4 version of e2fsprogs with this patch, and verified that the
2nd e2fsck pass finds the fileystem clean (i.e. first pass fixes it):

[root@inode obj]# /root/e2fsck  -y c0d0p5.e2i 
e2fsck 1.35 (28-Feb-2004)
/: recovering journal
Resize inode not valid.  Recreate? yes

/ contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Extended attribute block 98901 has reference count 23, should be 19.  Fix? yes

<much output snipped>

[root@inode obj]# /root/e2fsck  -y c0d0p5.e2i 
e2fsck 1.35 (28-Feb-2004)
/: clean, 4413/192000 files, 46048/383544 blocks

and it is mountable:

[root@inode obj]# mount -o loop c0d0p5.e2i mnt/
[root@inode obj]# ls mnt/
appl  dev   initrd  lost+found  mnt  proc  scripts       srv      tmp
....

-Eric

Before I hand out a modified package for customer use I'll need to create a cvs
branch & do an official build... I'll try to do that tonight, or possibly
tomorrow.  It'd be based on RHEL4U6's e2fsprogs version.

Thanks,

-Eric

Checked into CVS as e2fsprogs-1.35-12.10.el4

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0758.html