Bug 144771 - resize ext3 lvm volume fails
Summary: resize ext3 lvm volume fails
Alias: None
Product: Fedora
Classification: Fedora
Component: e2fsprogs
Version: 3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-01-11 14:21 UTC by Toni Schmidbauer
Modified: 2007-11-30 22:10 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-11-10 17:22:50 UTC

Attachments (Terms of Use)
output of lvm commands (4.44 KB, text/plain)
2005-01-11 14:25 UTC, Toni Schmidbauer
no flags Details
"tune2fs -l" output from before resize (1.47 KB, text/plain)
2005-01-17 17:48 UTC, Benjamin Scott
no flags Details
"tune2fs -l" output from after resize (1.46 KB, text/plain)
2005-01-17 17:49 UTC, Benjamin Scott
no flags Details
truncated output showing the first few errors from e2fsck (595 bytes, text/plain)
2005-01-17 17:49 UTC, Benjamin Scott
no flags Details
typescript (terminal capture) of fixing filesystem corruption (2.38 KB, text/plain)
2005-01-18 01:50 UTC, Benjamin Scott
no flags Details

Description Toni Schmidbauer 2005-01-11 14:21:24 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5)
Gecko/20050103 Firefox/1.0

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)
- lvresize
- resize2fs
- 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):

How reproducible:

Steps to Reproduce:
1.umount /home/asse
2.e2fsck -f /dev/universe/asse
3.lvresize -L 1G /dev/universe/asse
4.reize2fs /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

Additional info:

Comment 1 Toni Schmidbauer 2005-01-11 14:25:48 UTC
Created attachment 109609 [details]
output of lvm commands

Comment 2 Toni Schmidbauer 2005-01-14 10:20:21 UTC
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
4k blocksize.

Comment 3 Benjamin Scott 2005-01-17 17:48:31 UTC
Created attachment 109872 [details]
"tune2fs -l" output from before resize

Comment 4 Benjamin Scott 2005-01-17 17:49:06 UTC
Created attachment 109873 [details]
"tune2fs -l" output from after resize

Comment 5 Benjamin Scott 2005-01-17 17:49:37 UTC
Created attachment 109874 [details]
truncated output showing the first few errors from e2fsck

Comment 6 Benjamin Scott 2005-01-17 17:50:19 UTC
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
inode table."

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:

Comment 7 Barry K. Nathan 2005-01-17 18:41:01 UTC
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
the filesystem...

Comment 8 Toni Schmidbauer 2005-01-17 21:17:24 UTC
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.

Comment 9 Barry K. Nathan 2005-01-18 00:10:11 UTC
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.

Comment 10 Benjamin Scott 2005-01-18 01:49:46 UTC
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.

Comment 11 Benjamin Scott 2005-01-18 01:50:39 UTC
Created attachment 109908 [details]
typescript (terminal capture) of fixing filesystem corruption

Comment 12 Toni Schmidbauer 2005-01-18 18:25:18 UTC
fix needs to be integrated into fc3. sorry for the noise.

Comment 13 Douglas E. Warner 2005-02-07 23:40:53 UTC
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: 

Comment 14 Charles Lopes 2005-06-23 07:55:19 UTC
Shouldn't this be closed now that e2fsprogs 1.36 is in the updates?

Comment 15 Thomas Woerner 2005-11-10 17:22:50 UTC
Fixed in rawhide.

Note You need to log in before you can comment on or make changes to this bug.