1. 19 10月, 2007 37 次提交
  2. 18 10月, 2007 3 次提交
    • E
      ext4: lighten up resize transaction requirements · 14904107
      Eric Sandeen 提交于
      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.
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: NMingming Cao <cmm@us.ibm.com>
      Acked-by: NAndreas Dilger <adilger@clusterfs.com>
      14904107
    • E
      ext4: fix setup_new_group_blocks locking · 5b615287
      Eric Sandeen 提交于
      setup_new_group_blocks() manipulates the group descriptor block bh
      under the block_bitmap bh's lock.  It shouldn't matter since nobody
      but resize should be touching these blocks, but it's worth fixing up.
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: NMingming Cao <cmm@us.ibm.com>
      5b615287
    • A
      ext4: sparse fixes · ac39849d
      Aneesh Kumar K.V 提交于
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      ac39849d