On Dec 08, 2004 21:16 -0700, Stephen Warren wrote:
> I'm attempting to setup a box here to be a file-server for all my data.
> I'm attempting to resize an ext3 partition to demonstrate this
> capability to myself before fully committing to this system as the
> primary data storage. I'm having some problems resizing an ext3
> filesystem after I've resized the underlying logical volume. Following
> the ext3 resize, fsck spits out lots of errors like:
>
> Pass 1: Checking inodes, blocks, and sizes
> Group 49's inode table at 1605636 conflicts with some other fs block.
> Relocate<y>? no
>
> I believe that I'm following the correct procedure for resizing the
> filesystem. Any pointers greatly appreciated. Thanks.
>
> A complete transcript demonstrating this problem follows:
Thanks for the detail, it is clear I think what is happening.
> root@SEVERN:~# mke2fs /dev/severn_vg0/test
> mke2fs 1.35 (28-Feb-2004)
> max_blocks 1342177280, rsv_groups = 40960, rsv_gdb = 319
> Filesystem label=
> OS type: Linux
> Block size=4096 (log=2)
> Fragment size=4096 (log=2)
> 655360 inodes, 1310720 blocks
> 65536 blocks (5.00%) reserved for the super user
> First data block=0
> Maximum filesystem blocks=1342177280
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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.
> root@SEVERN:~# e2fsck -f /dev/severn_vg0/test
> e2fsck 1.35 (28-Feb-2004)
> Pass 1: Checking inodes, blocks, and sizes
> Group 49's inode table at 1605636 conflicts with some other fs block.
> Relocate<y>? no
>
> Group 1: block bitmap at 33089, inode bitmap at 33090, inode table at
> 33091
> 31933 free blocks, 16384 free inodes, 0 used directories
> Group 3: block bitmap at 98625, inode bitmap at 98626, inode table at
> 98627
> 31933 free blocks, 16384 free inodes, 0 used directories
> Group 5: block bitmap at 164161, inode bitmap at 164162, inode table
> at 164163
> 31933 free blocks, 16384 free inodes, 0 used directories
> Group 7: block bitmap at 229697, inode bitmap at 229698, inode table
> at 229699
> 31933 free blocks, 16384 free inodes, 0 used directories
All of these groups have backup group descriptors, as do all groups
numbered {3,5,7}^n. Note free blocks count.
> Group 49: block bitmap at 1605634, inode bitmap at 1605635, inode
> table at 1605636
> 32252 free blocks, 16384 free inodes, 0 used directories
This is the first group with backup descriptors created by resize2fs.
It doesn't have the reserved group blocks (about 300 or so) and e2fsck
is likely complaining about this.
This is obviously a bug that needs to be fixed. The good news is
that instead of resizing your filesystem while it is unmounted you can
resize it while it is mounted, and that shouldn't suffer from any of
these problems (and is much more convenient). You need the ext2resize
RPM from sourceforge (don't know why it isn't in FC2 if they have also
applied the patch to mke2fs):
ftp://rpmfind.net/linux/sourceforge/e/ex/ext2resize/ext2resize-1.1.19-1.i386.rpm
Then you can mke2fs a new filesystem, mount it, lvextend, and run
"ext2online /dev/severn_vg0/test" and it will grow to fill the LV.
There is also a tool that ships with LVM called "e2fsadm" which does
this for you, like "e2fsadm -L +5G /dev/severn_vg0/test" should do
both the lvextend and ext2online step at once.
You should also be able to properly resize it while unmounted with
ext2resize, but that is far less interesting...
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://members.shaw.ca/adilger/ http://members.shaw.ca/golinux/
Attachment:
pgp4x2FrP4Jtl.pgp
Description: PGP signature
_______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
