recovering failed resize2fs

[Curtis Doty]

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: http://www.greenkey.net/~curtis/linux/

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?

../C