Bug 176172

Summary:	e2fsck unable to check lvm: Corruption found in superblock
Product:	Red Hat Enterprise Linux 4	Reporter:	Rex Dieter <rdieter>
Component:	e2fsprogs	Assignee:	Thomas Woerner <twoerner>
Status:	CLOSED NOTABUG	QA Contact:	Jay Turner <jturner>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.0	CC:	sct, srevivo
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-01-05 14:32:48 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 Rex Dieter 2005-12-19 20:12:10 UTC

Just got done creating a lvm ext3 filesystem (~800GB), mke2fs'd it, checked for
badblocks, copied ~300GB data to it.  On server reboot, boot process stops on error:

Corruption found in superblock (r_blocks_count=97677300)
The superblock could not be read or does not describe a correct ext2 filesystem.

If I skip the fsck on boot, I can still mount it, and do anything I want (it
seems to work fine).

I'm about to start worrying, but on a whim, I noticed on e2fsprogs.sf.net, that
the latest version is 1.38 (vs rhel4's 1.35).  Grabbed development's
e2fsprogs-1.38-2.1.1 rebuilt it on my el4 box.  Tried it out.  Woah!  It
actually worked (or at least started to work before I interrupted it, and it
didn't complain about a corrupted superblock).

On the surface, it appears to the "Corruption found in superblock" (bogus?)
error is rooted in some e2fsprogs bug that was fixed somewhere between rhel4's
e2fsprogs-1.35-12.2.EL4 and developments' e2fsprogs-1.38-2.1.1

Comment 1 Rex Dieter 2006-01-05 14:32:48 UTC

From e2fsprogs' 1.36 Releaes Notes:
-----------------
The tune2fs program will not allow the user from setting a ridiculous
number of reserved blocks which would cause e2fsck to assume the
superblock was corrupt.  E2fsck's standards for what is a ridiculous
number of reserved block has also been relaxed to 50% of the blocks in
the filesystem.
-----------------

Turns out in this case, we *had* set the reserved block % to 50%, so it's
(probably) NOTABUG, though an upgrade to handle this situation would still be nice.