Bug 425955 - resize2fs online resize fails with small journal
resize2fs online resize fails with small journal
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Martin Jenner
: 334741 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2007-12-17 07:57 EST by Bryn M. Reeves
Modified: 2011-01-24 17:24 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-20 15:10:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch from upstream (4.39 KB, patch)
2007-12-17 07:59 EST, Bryn M. Reeves
no flags Details | Diff

  None (edit)
Description Bryn M. Reeves 2007-12-17 07:57:49 EST
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) 
    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

        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@redhat.com>
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@linux-foundation.org: coding-style fixes]
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Acked-by: Andreas Dilger <adilger@clusterfs.com>
    Cc: <linux-ext4@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Version-Release number of selected component (if applicable):

How reproducible:

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:
Comment 1 Bryn M. Reeves 2007-12-17 07:59:43 EST
Created attachment 289779 [details]
patch from upstream
Comment 2 Eric Sandeen 2008-01-08 14:00:41 EST
Bug #166038 is similar, for RHEL4.  This patch has been upstream for a while, it
should probably be considered for RHEL.
Comment 5 Eric Sandeen 2008-03-11 16:18:18 EDT
*** Bug 334741 has been marked as a duplicate of this bug. ***
Comment 7 RHEL Product and Program Management 2008-04-08 17:19:52 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 9 Eric Sandeen 2008-06-19 11:35:17 EDT
Sent to rhkernel-list 06/19/08
Comment 10 Don Zickus 2008-07-18 16:06:43 EDT
in kernel-2.6.18-98.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5
Comment 11 Issue Tracker 2008-07-21 10:30:44 EDT
------- Comment From john_taylor@uk.ibm.com 2008-07-21 05:32 EDT-------
looks OK to me based on my testing. I expect that RedHat will probably
this to RHEL 4 AS s390 & s390x.

This event sent from IssueTracker by jkachuck 
 issue 142505
Comment 14 errata-xmlrpc 2009-01-20 15:10:38 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.