Cloning for RHEL5 since it has this problem as well (though the tool there is
"resize2fs"

+++ This bug was initially created as a clone of Bug #166038 +++

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524
Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
ext2online resize failed:
2 out of 8 system I recently install are having a problem with ext2online
resizing.



Version-Release number of selected component (if applicable):
e2fsprogs-1.35-12.1.EL4
kernel-2.6.9-11.EL
lvm2-2.01.08-1.0.RHEL4
device-mapper-1.01.01-1.RHEL4

How reproducible:
Sometimes

Steps to Reproduce:
1. create lvm: pv, vg, lv
2. format the lv
3. mount the lv
4. lvextend -l +10 /dev/test0/scratch
5. ext2online /dev/test0/scratch
  

Actual Results:  # ext2online -v -d /dev/test0/scratch
ext2online v1.1.18 - 2001/03/18 for EXT2FS 0.5b
ext2_open
ext2_bcache_init
new filesystem size 61440
ext2_determine_itoffset
setting itoffset to +35
group 2 inode table has offset 2, not 35
group 4 inode table has offset 2, not 35
ext2_get_reserved
Found 31 blocks in s_reserved_gdt_blocks
using 31 reserved group descriptor blocks

5 old groups, 1 blocks
8 new groups, 1 blocks
ext2_ioctl: EXTEND group to 40961 blocks
creating group   5 with  8192 blocks (rsvd = 31, newgd =  1)
using itoffset of 35
new block bitmap is at 0xa022
new inode bitmap is at 0xa023
new inode table is at 0xa024-0xa123
new group has 7901 free blocks
new group has 2048 free inodes (256 blocks)
ext2_ioctl: ADD group 5
ext2online: ext2_ioctl: No space left on device

ext2online: unable to resize /dev/mapper/test0-scratch

Expected Results:  ext2online return success and
lv (lvdisplay) and fs (df) size should show the same size


Additional info:

-- Additional comment from andrekusuma on 2005-08-15 23:52 EST --
Created an attachment (id=117784)
The detailed and verbose commands

verbose command and information about the filesystem or LVM.
workaround also provided

-- Additional comment from andrekusuma on 2005-08-15 23:54 EST --
*** Bug 166039 has been marked as a duplicate of this bug. ***

-- Additional comment from twoerner on 2006-08-01 10:48 EST --
There is an update package of e2fsprogs for RHEL-4: e2fsprogs-1.35-12.3.EL4

Is this version working for you?

-- Additional comment from andrekusuma on 2006-08-01 15:01 EST --
Too old to try again. didn't have the system anymore

-- Additional comment from paolo.penzo on 2006-09-15 05:41 EST --
I've got the same issue on RH 4.4 (e2fsprogs-1.35-12.4.EL4) running on s390x
(zVM) but not on i686. Thi is the error I got:

ext2online -v -d /dev/vg00010051_01/lvtest

ext2online v1.1.18 - 2001/03/18 for EXT2FS 0.5b
ext2_open
ext2_bcache_init
new filesystem size 38912
ext2_determine_itoffset
setting itoffset to +10
ext2_get_reserved
Found 6 blocks in s_reserved_gdt_blocks
using 6 reserved group descriptor blocks

1 old groups, 1 blocks
2 new groups, 1 blocks
ext2_ioctl: EXTEND group to 32768 blocks
creating group   1 with  6144 blocks (rsvd =  6, newgd =  1)
using itoffset of 10
new block bitmap is at 0x8008
new inode bitmap is at 0x8009
new inode table is at 0x800a-0x8349
new group has 5302 free blocks
new group has 26624 free inodes (832 blocks)
ext2_ioctl: ADD group 1
ext2online: ext2_ioctl: No space left on device

ext2online: unable to resize /dev/mapper/vg00010051_01-lvtest
root@lx000000010051 ~ #


-- Additional comment from kjetilho.no on 2006-10-19 13:03 EST --
why is the priority "low" on this bug?

I don't think it is very "enterprise" to suggest a couple of hours of downtime
as a workaround...  (yes, this is how long our filesystem will take to resize
offline, since an fsck is required before resize2fs.)


-- Additional comment from esandeen on 2007-10-02 18:47 EST --
Without dmesg output it's hard to know for sure, but it's likely that this is
the same issue as here:

http://marc.info/?l=linux-ext4&m=119126680223394&w=4

in which the transaction to grow the filesystem is too large for the existing
journal.

My patch above should address this, can someone who has hit this provide dmesg
output to verify that it is the same issue?

(See also bug 160612)

Note that another simpler workaround is to create a larger journal... although
that defeats the purpose of online resizing, if you have to unmount to
"workaround" you may as well just do offline resizing.

Thanks,
-Eric

-- Additional comment from esandeen on 2007-10-02 18:47 EST --
Oh, and switch to kernel, since the bug is actually there.

-- Additional comment from esandeen on 2007-10-02 18:53 EST --
*** Bug 160612 has been marked as a duplicate of this bug. ***