Red Hat Bugzilla – Bug 144771
resize ext3 lvm volume fails
Last modified: 2007-11-30 17:10:58 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5)
Description of problem:
tried to resize an ext3 lvm volume, but after resize2fs e2fsck
complains. i followed the instructions in the lvm howto.
- umount the fs
- e2fsck -f (just to be sure)
- e2fsck -f -> BANG!
it's possible to mount the fs if i skip the fsck after resize2fs, i
just don't trust it anymore... (the size is correct).
i tried to resize2fs specifying a certain size (200m), same effect.
resizing an empty fs on the same lv, same effect.
any help would be appreciated
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2.e2fsck -f /dev/universe/asse
3.lvresize -L 1G /dev/universe/asse
5.e2fsck -f /dev/universe/asse
Actual Results: fsck thinks filesystem is dirty
Expected Results: fsck should pass, and fs should be clean
Created attachment 109609 [details]
output of lvm commands
i checked if this is related to bug #144486, but without success. same
happens with a 4k blocksize ext3. so i can reproduce this with 1k and
Created attachment 109872 [details]
"tune2fs -l" output from before resize
Created attachment 109873 [details]
"tune2fs -l" output from after resize
Created attachment 109874 [details]
truncated output showing the first few errors from e2fsck
I think I just hit this. Well, I know I hit *something*, and this
sounds just like it.
I resized a filesystem from around 80 GB to around 160 GB using
"resize2fs". I forced "e2fsck" before the resize and everything was
fine. I forced "e2fsck" again after the resize and I got tons of errors:
Group X's inode table at Y conflicts with some other fs block.
Filesystem blocksize is 4096 bytes.
I have attached "before" and "after" output from "tune2fs -l", as well
as the start of output from "e2fsck".
I did some searching and found ta partialhat on 9 Dec 2004, Andreas
Dilger reported in a message to the ext3-users list (links below):
"This implies that the FC3 e2fsprogs has the ext2online patch for
mke2fs applied so that it is reserving block group descriptors for
online (mounted) filesystem resizing. It seems that resize2fs isn't
taking these reserved blocks into account when it is allocating the
So it would appear the problem is in resize2fs and possibly e2fsck,
and how they handle the changes in the ext2online patch. LVM has
nothing to do with it (other then the fact that using LVM tends to
lead to filesystem resizing).
Theodore Ts'o responded later in the same thread with a comment that I
took to mean e2fsck needs a patch to fix things properly. A "release
canidate" 1.36-rc1 of e2fsprogs was made available on 7 Jan 2004 which
I think includes said patch.
This issue may (or may not) be related to bug #140762 and/or bug
#144486, which appears to have similar (but not the same) symptoms.
Mailing list archive references:
Start of original problem-report thread:
Andreas Dilger's first response:
Ted Ts'o's response:
Announcement of e2fsprogs-1.36-rc1:
I also hit the phenomenon mentioned in comment #6. I tried letting
"e2fsck -f -y" run to completion, but it's taking long enough that it
will be many times faster just to reinstall everything. :(
Actually, maybe I'll try the new e2fsprogs and see if it can recover
thanks to benjamin scott for the hint to e2fsprogs 1.36-rc1. this
seems to be fixed in that version. resizing the unmounted filesystem
works as expected, e2fsck-1.36-rc1 doesn't complain.
fixing the filesystem as mentioned in ted ts'o's email works to.
The new e2fsprogs appears to have recovered my filesystem too.
Toni, would you mind reopening this bug? Yes, there's now an upstream
fix for this bug, but as far as I can tell, that fix hasn't even made
its way into fc-devel yet.
I tried e2fsprogs-1.36-rc1. Right away, "e2fsck -n" (before anything
else) appeared to have a better idea of what was going on, with the
message "Resize inode is corrupt". I then followed Ted T'so's
instructions (typescript to be attached), answered "yes" to all the
fix questions, and things appear to be much better now. Spot checks
of the filesystem all look good.
Created attachment 109908 [details]
typescript (terminal capture) of fixing filesystem corruption
fix needs to be integrated into fc3. sorry for the noise.
I too have been having this problem; using e2fsprogs 1.36 (released
Feb 5th) worked fine for fixing the e2fsck problems and resizing the
Thread describing my problems starts here:
Shouldn't this be closed now that e2fsprogs 1.36 is in the updates?
Fixed in rawhide.