[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: recovering failed resize2fs



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]