Bug 144771
| Summary: | resize ext3 lvm volume fails | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Toni Schmidbauer <toni> |
| Component: | e2fsprogs | Assignee: | Thomas Woerner <twoerner> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3 | CC: | agk, andriusb, barryn, brwk, bscott, jpyeron, sct, silfreed, tjarls, zing |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-11-10 17:22:50 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
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 4k blocksize. 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.
Relocate?
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:
http://listman.redhat.com/archives/ext3-users/2004-December/msg00018.html
Andreas Dilger's first response:
http://listman.redhat.com/archives/ext3-users/2004-December/msg00020.html
Ted Ts'o's response:
http://listman.redhat.com/archives/ext3-users/2004-December/msg00030.html
Announcement of e2fsprogs-1.36-rc1:
http://listman.redhat.com/archives/ext3-users/2005-January/msg00013.html
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... 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 partition. Thread describing my problems starts here: https://listman.redhat.com/archives/ext3-users/2005-February/msg00006.html -Doug Shouldn't this be closed now that e2fsprogs 1.36 is in the updates? Fixed in rawhide. |
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 regards toni Version-Release number of selected component (if applicable): lvm2-2.00.25-1.01 How reproducible: Always 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: