1. 22 10月, 2012 1 次提交
  2. 26 9月, 2012 2 次提交
  3. 20 9月, 2012 1 次提交
  4. 19 9月, 2012 1 次提交
    • T
      ext4: fix online resizing when the # of block groups is constant · 59e31c15
      Theodore Ts'o 提交于
      Commit 1c6bd717 introduced a regression where an online resize
      operation which did not change the number of block groups would fail,
      i.e:
      
      	mke2fs -t /dev/vdc 60000
      	mount /dev/vdc
      	resize2fs /dev/vdc 60001
      
      This was due to a bug in the logic regarding when to try converting
      the filesystem to use meta_bg.
      
      Also fix up a number of other minor issues with the online resizing
      code: (a) Fix a sparse warning; (b) only check to make sure the device
      is large enough once, instead of multiple times through the resize
      loop.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      59e31c15
  5. 13 9月, 2012 3 次提交
  6. 05 9月, 2012 7 次提交
  7. 23 7月, 2012 2 次提交
  8. 10 7月, 2012 1 次提交
    • T
      ext4: fix overhead calculation used by ext4_statfs() · 952fc18e
      Theodore Ts'o 提交于
      Commit f975d6bc introduced bug which caused ext4_statfs() to
      miscalculate the number of file system overhead blocks.  This causes
      the f_blocks field in the statfs structure to be larger than it should
      be.  This would in turn cause the "df" output to show the number of
      data blocks in the file system and the number of data blocks used to
      be larger than they should be.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@kernel.org
      952fc18e
  9. 29 5月, 2012 2 次提交
  10. 30 4月, 2012 4 次提交
  11. 21 3月, 2012 1 次提交
  12. 20 3月, 2012 1 次提交
  13. 21 2月, 2012 1 次提交
    • L
      ext4: fix resize when resizing within single group · a0ade1de
      Lukas Czerner 提交于
      When resizing file system in the way that the new size of the file
      system is still in the same group (no new groups are added), then we can
      hit a BUG_ON in ext4_alloc_group_tables()
      
      BUG_ON(flex_gd->count == 0 || group_data == NULL);
      
      because flex_gd->count is zero. The reason is the missing check for such
      case, so the code always extend the last group fully and then attempt to
      add more groups, but at that time n_blocks_count is actually smaller
      than o_blocks_count.
      
      It can be easily reproduced like this:
      
      mkfs.ext4 -b 4096 /dev/sda 30M
      mount /dev/sda /mnt/test
      resize2fs /dev/sda 50M
      
      Fix this by checking whether the resize happens within the singe group
      and only add that many blocks into the last group to satisfy user
      request. Then o_blocks_count == n_blocks_count and the resize will exit
      successfully without and attempt to add more groups into the fs.
      
      Also fix mixing together block number and blocks count which might be
      confusing and can easily lead to off-by-one errors (but it is actually
      not the case here since the two occurrence of this mix-up will cancel
      each other).
      Signed-off-by: NLukas Czerner <lczerner@redhat.com>
      Reported-by: NMilan Broz <mbroz@redhat.com>
      Reviewed-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      a0ade1de
  14. 05 1月, 2012 3 次提交
  15. 04 1月, 2012 9 次提交
  16. 10 9月, 2011 1 次提交
    • T
      ext4: Rename ext4_free_blks_{count,set}() to refer to clusters · 021b65bb
      Theodore Ts'o 提交于
      The field bg_free_blocks_count_{lo,high} in the block group
      descriptor has been repurposed to hold the number of free clusters for
      bigalloc functions.  So rename the functions so it makes it easier to
      read and audit the block allocation and block freeing code.
      
      Note: at this point in bigalloc development we doesn't support
      online resize, so this also makes it really obvious all of the places
      we need to fix up to add support for online resize.
      Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>
      021b65bb