Bug 227670 - resize inode not valid
resize inode not valid
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: e2fsprogs (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Eric Sandeen
Jay Turner
Depends On:
  Show dependency treegraph
Reported: 2007-02-07 09:38 EST by Thomas J. Baker
Modified: 2015-01-07 19:15 EST (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2007-0758
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-15 11:01:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
backport of upstream patch (4.16 KB, patch)
2007-08-06 17:40 EDT, Eric Sandeen
no flags Details | Diff

  None (edit)
Description Thomas J. Baker 2007-02-07 09:38:38 EST
I've got a large filesystem on a RAID that, after having some disk problems
which have since been resolved, has left the filesystem in a state where each
reboot it complains about 'resize inode not valid'. A manual fsck is required
where it asks to recreate the resize inode but it apparently never works. So
this multiTB filesystem needs to be manually checked each reboot which makes for
hours of downtime.

The e2fsprogs release notes page addresses several bugs about the resize inode
in several releases that are newer than the 1.35 base version shipped with
RHEL4. I know RH applies several patches against this base version so I don't
know if this is supposed to be fixed or not.
Comment 1 Eric Sandeen 2007-05-07 16:38:58 EDT
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?


Comment 2 Thomas J. Baker 2007-05-08 10:13:06 EDT
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

The fsck says it recreates the inode. See #1.
Comment 3 Eric Sandeen 2007-05-08 10:38:51 EDT
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?


Comment 4 Thomas J. Baker 2007-05-08 10:46:29 EDT
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

Comment 5 Eric Sandeen 2007-08-06 16:45:22 EDT
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.

Comment 6 Eric Sandeen 2007-08-06 17:10:22 EDT
seems fixed in e2fsprogs-1.38 and beyond.

Comment 7 Eric Sandeen 2007-08-06 17:19:46 EDT
This mod fixed it:

(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).
Comment 8 Eric Sandeen 2007-08-06 17:40:40 EDT
Created attachment 160773 [details]
backport of upstream patch

This patch at least gets it to the point where the filesystem is mountable
Comment 9 Eric Sandeen 2007-08-06 17:42:54 EDT
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

Comment 11 Eric Sandeen 2007-08-06 21:46:50 EDT
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.


Comment 18 Eric Sandeen 2007-08-13 18:08:22 EDT
Checked into CVS as e2fsprogs-1.35-12.10.el4
Comment 26 errata-xmlrpc 2007-11-15 11:01:29 EST
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.


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