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:
...

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

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...

Thanks everyone for your help.

I have one question and another problem:

Question:

On the filesystem that I ran resize2fs on, is it now broken beyond
repair? I originally found the problem on a 'real' data volume. After
the resize, I can certainly mount it (read-only - didn't try rw) and
pull the data off it, but I assume that the fsck errors are legitimate
and the fs is corrupt, such that I should run mke2fs again from scratch?

This isn't a huge problem, since I was attempting to resize my "backup"
LV, so it was just copies of other data...

Problem:

Well, I do have ext2online installed, although there's no e2fsadm. I'll
have to check for other RPMs...

So, I went ahead and tried ext2online, but I get a bunch of errors
during the execution - it's indicating my kernel doesn't have online
resize support compiled in. I would have assumed the FC(3) kernel did,
but I guess I should go check. Still, the debug trace from ext2online
indicates some other errors about allocating things before the kernel
problem.

creating group 40 with 32768 blocks (rsvd = 319, newgd = 1)
using itoffset of 323
new block bitmap is at 0x140000
new inode bitmap is at 0x140001
new inode table is at 0x140143-0x140342
new group has 32254 free blocks
new group has 16384 free inodes (512 blocks)
mark 16384 unavailable end inodes used

creating group 41 with 32768 blocks (rsvd = 319, newgd = 1)
using itoffset of 323
new block bitmap is at 0x148000
new inode bitmap is at 0x148001
new inode table is at 0x148143-0x148342
new group has 32254 free blocks
new group has 16384 free inodes (512 blocks)
mark 16384 unavailable end inodes used

... same message for many other groups

creating group 49 with 32768 blocks (rsvd = 319, newgd = 1)
using itoffset of 323
new block bitmap is at 0x188141
new inode bitmap is at 0x188142
new inode table is at 0x188143-0x188342
new group has 31933 free blocks
new group has 16384 free inodes (512 blocks)
mark superblock 0x188000 used
mark group desc. 0x188001-0x188001 used
mark reserved descriptors 0x188002-0x188140 used
finding 0x188002 in inode
adding 0x188002 to inode
add 0 as direct block
finding 0x188003 in inode
adding 0x188003 to inode
add 1 as direct block
finding 0x188004 in inode
adding 0x188004 to inode
add 2 as direct block

creating group 50 with 32768 blocks (rsvd = 319, newgd = 1)
using itoffset of 323
new block bitmap is at 0x190000
new inode bitmap is at 0x190001
new inode table is at 0x190143-0x190342
new group has 32254 free blocks
new group has 16384 free inodes (512 blocks)
mark 16384 unavailable end inodes used

... same message for many groups

creating group 68 with 32768 blocks (rsvd = 319, newgd = 1)
using itoffset of 323
new block bitmap is at 0x220000
new inode bitmap is at 0x220001
new inode table is at 0x220143-0x220342
new group has 32254 free blocks
new group has 16384 free inodes (512 blocks)
mark 16384 unavailable end inodes used

creating group 69 with 32768 blocks (rsvd = 319, newgd = 1)
using itoffset of 323
new block bitmap is at 0x228000
new inode bitmap is at 0x228001
new inode table is at 0x228143-0x228342
new group has 32254 free blocks
new group has 16384 free inodes (512 blocks)
mark 16384 unavailable end inodes used
creating group 79 with 32768 blocks (rsvd = 319, newgd = 1)
using itoffset of 323
new block bitmap is at 0x278000
new inode bitmap is at 0x278001
new inode table is at 0x278143-0x278342
new group has 32254 free blocks
new group has 16384 free inodes (512 blocks)
mark 16384 unavailable end inodes used