Bug 208322

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