recovering failed resize2fs

Curtis Doty Curtis at
Sat Oct 18 23:20:13 UTC 2008

4:29pm Theodore Tso said:

> On Sat, Oct 18, 2008 at 12:55:56PM -0700, Curtis Doty wrote:
>> While attempting to expand a 1.64T ext4 volume to 2.18T the F9 kernel
>> deadlocked. (I have photo of screen/oops if anybody's interested.)
> Yes, that would be useful, thanks.

Three photos of same:

The rest had scrolled off, so maybe that soft lockup was a secondary 
effect rather than true cause? It was re-appearing every minute.

>> Now after recovery, the filesystem won't mount
>>   EXT4-fs: ext4_check_descriptors: Block bitmap for group 13413 not in
>> group (block 0)!<3>EXT4-fs: group descriptors corrupted!
>> and fsck won't run:
>>   fsck.ext4: Group descriptors look bad... trying backup blocks...
>>   inst: recovering journal
>>   fsck.ext4: unable to set superblock flags on inst
> Hmm... This sounds like the needs recovery flag was set on the backup
> superblock, which should never happen.  Before we try something more
> extreme, see if this helps you:
> e2fsck -b 32768 -B 4096 /dev/where-inst-is-located
> That forces the use of the backup superblock right away, and might
> help you get past the initial error.

Same as before. :-(

# e2fsck -b32768 -B4096 -C0 /dev/dat/inst
e2fsck 1.41.0 (10-Jul-2008)
inst: recovering journal
e2fsck: unable to set superblock flags on inst

It appears *all* superblocks are same as that first 32768 by iterating 
over all superblocks shown in mkfs -n output says so.

I'm inclined to just force reduce the underlying lvm. It was 100% full 
before I extended and tried to resize. And I know the only writes on the 
new lvm extent would have been from resize2fs. It that wise?


More information about the Ext3-users mailing list