Bug 425955

Summary: resize2fs online resize fails with small journal
Product: Red Hat Enterprise Linux 5 Reporter: Bryn M. Reeves <bmr>
Component: kernelAssignee: Eric Sandeen <esandeen>
Status: CLOSED ERRATA QA Contact: Martin Jenner <mjenner>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.1CC: akarlsso, esandeen, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-20 20:10:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch from upstream none

Description Bryn M. Reeves 2007-12-17 12:57:49 UTC
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:

Comment 1 Bryn M. Reeves 2007-12-17 12:59:43 UTC
Created attachment 289779 [details]
patch from upstream

Comment 2 Eric Sandeen 2008-01-08 19:00:41 UTC
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 20:18:18 UTC
*** Bug 334741 has been marked as a duplicate of this bug. ***

Comment 7 RHEL Program Management 2008-04-08 21:19:52 UTC
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
release.

Comment 9 Eric Sandeen 2008-06-19 15:35:17 UTC
Sent to rhkernel-list 06/19/08

Comment 10 Don Zickus 2008-07-18 20:06:43 UTC
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 14:30:44 UTC
------- Comment From john_taylor.com 2008-07-21 05:32 EDT-------
looks OK to me based on my testing. I expect that RedHat will probably
backport
this to RHEL 4 AS s390 & s390x.


This event sent from IssueTracker by jkachuck 
 issue 142505

Comment 14 errata-xmlrpc 2009-01-20 20:10:38 UTC
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.

http://rhn.redhat.com/errata/RHSA-2009-0225.html