In FC6test2, the ext2online program has (apparantly?) been deprecated in favor of resize2fs. I have the following situation: $ lvs | grep -E 'usr|LV' LV VG Attr LSize Origin Snap% Move Log Copy% usr os -wi-ao 11.00G $ tune2fs -l /dev/os/usr | grep -E 'Block (count|size)' Block count: 10485761 Block size: 1024 Meaning, the /dev/os/usr logical volume is 11G, but the filesystem on /dev/os/usr is (10G + 1K). When I attempt to run resize2fs, the following error message is printed: $ resize2fs -p /dev/os/usr resize2fs 1.39 (29-May-2006) Filesystem at /dev/os/usr is mounted on /usr; on-line resizing required Performing an on-line resize of /dev/os/usr to 11534336 (1k) blocks. resize2fs: Operation not permitted While trying to add group #1280 Simultaneously, this message is syslogged: Sep 27 16:34:38 example kernel: EXT3-fs warning (device dm-3): ext3_group_add: No reserved GDT blocks, can't resize I googled for "reserved GDT blocks" and found squat.
See also this debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380548 and recent e2fsprogs commits to clarify the errors: http://thunk.org/hg/e2fsprogs/?cs=bcc70a8dd385 James, it looks like your filesystem does not have the online_resize feature. This is on by default in e2fsprogs 1.39 and later, as configured by the mke2fs.conf file. Thomas, it would probably make sense to include that patch in our 1.39 package?
Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer test releases. We're cleaning up the bug database and making sure important bug reports filed against these test releases don't get lost. It would be helpful if you could test this issue with a released version of Fedora or with the latest development / test release. Thanks for your help and for your patience. [This is a bulk message for all open FC5/FC6 test release bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Closing this one; it's more a misunderstanding than a bug. The filesystem in question does not have the online_resize feature; was probably made with old mkfs. later e2fsprogs (1.40.2, in F7 and F8...) will be more explicit about the reason for the failure. Thanks, -Eric
[Apologies for the radio silence; I was off chasing other bugs.] I'm not sure what you mean by "online_resize" feature. Do you mean the "resize_inode" feature? Because the resize fails even with the resize_inode feature: $ lvcreate -L 512M -n test os Logical volume "test" created $ mke2fs -q -b -4096 -O resize_inode -j /dev/os/test $ mkdir /test $ mount /dev/os/test /test $ lvresize -L 1G /dev/os/test Extending logical volume test to 1.00 GB Logical volume test successfully resized $ tune2fs -l /dev/os/test | grep features Filesystem features: has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file $ resize2fs -p /dev/os/test resize2fs 1.40.2 (12-Jul-2007) Filesystem at /dev/os/test is mounted on /test; on-line resizing required old desc_blocks = 1, new_desc_blocks = 1 Performing an on-line resize of /dev/os/test to 262144 (4k) blocks. resize2fs: No space left on device While trying to add group #4 When resize2fs prints its error message, this message is syslogged: Sep 19 16:51:28 example kernel: JBD: resize2fs wants too many credits (1026 > 1024) If, however, I repeat the same experiement, but create the filesystem at 1GB in size and then resize to 2GB, everything's fine: $ lvcreate -L 1G -n test os Logical volume "test" created $ mke2fs -q -b -4096 -O resize_inode -j /dev/os/test $ mkdir /test $ mount /dev/os/test /test $ lvresize -L 2G /dev/os/test Extending logical volume test to 2.00 GB Logical volume test successfully resized $ tune2fs -l /dev/os/test | grep features Filesystem features: has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file $ resize2fs -p /dev/os/test resize2fs 1.40.2 (12-Jul-2007) Filesystem at /dev/os/test is mounted on /test; on-line resizing required old desc_blocks = 1, new_desc_blocks = 1 Performing an on-line resize of /dev/os/test to 524288 (4k) blocks. The filesystem on /dev/os/test is now 524288 blocks long. The filesystem features are identical, yet online resizing fails in case 1 (512MB -> 1GB) and succeeds in case 2 (1GB -> 2GB). I'm reopening this bug. If I've misunderstood your explanation (e.g., I didn't do something necessary for online resizing when I created the filesystem), feel free to close it again.
Bwah, I'm an idiot; I confused this bug with bug 160612. The explanation in comment #1 seems reasonable. Unfortunately, the system in question has long since been reinstalled, and the new system doesn't exhibit the problem, so there's no way now that I can test to see whether the problem was that the resize_inode feature was missing. Re-closing.
> I'm not sure what you mean by "online_resize" feature. Do you mean the > "resize_inode" feature? right, sorry. And, I do still need to get to the bottom of bug 160612 Thanks :) -Eric