Description of problem:
A problem with online resizing of ext3 file systems having a small journal was
reported to the ext4-devel mailing list back in July:

http://marc.info/?l=linux-ext4&m=118416244220415&w=2 [Ext3 onlie resize failure
due to small journal size]

This problem shows itself as an error during online resizing:

    # resize2fs  /dev/mapper/testvg-tmp
    resize2fs 1.39 (29-May-2006)
    Filesystem at /dev/mapper/testvg-tmp is mounted on /tmp; on-line 
    resizing required
    Performing an on-line resize of /dev/mapper/testvg-tmp to 186368 (4k) 
    blocks.
    resize2fs: No space left on device While trying to add group #4

With a journal size of 16M and 1024 inode table blocks per group we
exceed the limit on the number of buffers per transaction applied in
setup_new_group_blocks():

        handle = ext3_journal_start_sb(sb, reserved_gdb + gdblocks +
                                       2 + sbi->s_itb_per_group);

We are requesting for a a credit value of 2 + sbi->s_itb_per_group
which in the case of the file system below is 1026 while the 
max_transaction credits possible is 1024 for the fs.

journal->j_maxlen = inode->i_size / blocksize = 16M/4K = 4K

journal->j_max_transaction_buffers = journal->j_maxlen / 4 = 1K

journal->j_max_transaction_buffers = 1024.

Eric proposed a patch to resize the transaction and re-start to allow such
an online resize to succeed:

commit 1ad6ecf9146e85ccb4e0bce70b91a93f57145c72
Author: Eric Sandeen <sandeen>
Date:   Tue Oct 16 23:30:28 2007 -0700

    ext3: lighten up resize transaction requirements
    
    When resizing online, setup_new_group_blocks attempts to reserve a
    potentially very large transaction, depending on the current filesystem
    geometry.  For some journal sizes, there may not be enough room for this
    transaction, and the online resize will fail.
    
    The patch below resizes & restarts the transaction as necessary while
    setting up the new group, and should work with even the smallest journal.
    
    Tested with something like:
    
    [root@newbox ~]# dd if=/dev/zero of=fsfile bs=1024 count=32768
    [root@newbox ~]# mkfs.ext3 -b 1024 fsfile 16384
    [root@newbox ~]# mount -o loop fsfile mnt/
    [root@newbox ~]# resize2fs /dev/loop0
    resize2fs 1.40.2 (12-Jul-2007)
    Filesystem at /dev/loop0 is mounted on /root/mnt; on-line resizing required
    old desc_blocks = 1, new_desc_blocks = 1
    Performing an on-line resize of /dev/loop0 to 32768 (1k) blocks.
    resize2fs: No space left on device While trying to add group #2
    [root@newbox ~]# dmesg | tail -n 1
    JBD: resize2fs wants too many credits (258 > 256)
    [root@newbox ~]#
    
    With the below change, it works.
    
    [akpm: coding-style fixes]
    Signed-off-by: Eric Sandeen <sandeen>
    Acked-by: Andreas Dilger <adilger>
    Cc: <linux-ext4.org>
    Signed-off-by: Andrew Morton <akpm>
    Signed-off-by: Linus Torvalds <torvalds>


Version-Release number of selected component (if applicable):
kernel-2.6.18-8.el5

How reproducible:
100%

Steps to Reproduce:
1. Attempt to online resize a file system created as above

Actual results:
    resize2fs: No space left on device While trying to add group #2
    [root@newbox ~]# dmesg | tail -n 1
    JBD: resize2fs wants too many credits (258 > 256)

Expected results:
No error, file system successfully resized.

Additional info: