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
_______________________________________________
Ext3-users mailing list
Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users
