Bug 215808

Summary: e2fsprogs looping on inode 8
Product: Red Hat Enterprise Linux 4 Reporter: Dan Carpenter <error27>
Component: e2fsprogsAssignee: Eric Sandeen <esandeen>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Jay Turner <jturner>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.4CC: sct, srevivo
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-02 19:04:24 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dan Carpenter 2006-11-15 20:59:55 UTC 
Description of problem:
fsck seems to think every single block belongs to inode 8.
Illegal block #219444 (2338623074) in inode 8.  CLEARED.
Illegal block #219445 (2340324616) in inode 8.  CLEARED.

Version-Release number of selected component (if applicable):
e2fsprogs-1.35-12.4.EL4.x86_64

How reproducible:  Extremely difficult

Additional info:

One of our customers had a corrupted filesystem on software RAID.
They ran fsck on the file system and it sat for 60 hours on inode 8 complaining
about each consecutive block.

At first they were using e2fsprogs-1.35-12.3.EL4.x86_64 but they installed
e2fsprogs-1.35-12.4.EL4.x86_64 and tried again and they got the same errors with
inode 8.

There are reports on the internet that this bug was fixed in version 1.36.
http://kangry.com/topics/viewcomment.php?index=221
https://listman.redhat.com/archives/ext3-users/2005-February/msg00048.html
Comment 1 Eric Sandeen 2007-10-02 19:04:24 UTC 
Dan, I don't think I'll be able to make progress on this one due to lack of
information and the age of the bug.  I apologize for the very late initial
reply, but I've recently been going through a backlog of e2fsprogs bugs that
were somewhat recently assigned to me.

The redhat.com ext3-users list message above doesn't necessarily look like the
same situation; in that case e2fsck seemed to be looping.

In your case, it appears that the list of blocks for the journal inode (8) is
bad.  It may in fact be a very corrupt filesystem - ideally I'd expect it to
give up before 60 hours go by, based on some hunch that this journal inode is
beyond hope.  However, without knowing the details of what was wrong with your
fileystem, it'd be tough to fix.  In the future, creating an e2image of the
filesystem would allow for further analysis.

If there is any more information you can provide which may help get to the root
cause of, or solution to, this bug - please feel free to reopen.

Thanks,
-Eric