1. 10 Jan, 2011 5 commits
    • Eric Sandeen's avatar
      ext4: don't pass entire map to check_eofblocks_fl · d002ebf1
      Eric Sandeen authored
      
      
      Since check_eofblocks_fl() only uses the m_lblk portion of the map
      structure, we may as well pass that directly, rather than passing the
      entire map, which IMHO obfuscates what parameters check_eofblocks_fl()
      cares about.  Not a big deal, but seems tidier and less confusing, to
      me.
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      d002ebf1
    • Jiaying Zhang's avatar
      ext4: flush the i_completed_io_list during ext4_truncate · 3889fd57
      Jiaying Zhang authored
      
      
      Ted first found the bug when running 2.6.36 kernel with dioread_nolock
      mount option that xfstests #13 complained about wrong file size during fsck.
      However, the bug exists in the older kernels as well although it is
      somehow harder to trigger.
      
      The problem is that ext4_end_io_work() can happen after we have truncated an
      inode to a smaller size. Then when ext4_end_io_work() calls 
      ext4_convert_unwritten_extents(), we may reallocate some blocks that have 
      been truncated, so the inode size becomes inconsistent with the allocated
      blocks. 
      
      The following patch flushes the i_completed_io_list during truncate to reduce 
      the risk that some pending end_io requests are executed later and convert 
      already truncated blocks to initialized. 
      
      Note that although the fix helps reduce the problem a lot there may still 
      be a race window between vmtruncate() and ext4_end_io_work(). The fundamental
      problem is that if vmtruncate() is called without either i_mutex or i_alloc_sem
      held, it can race with an ongoing write request so that the io_end request is
      processed later when the corresponding blocks have been truncated.
      
      Ted and I have discussed the problem offline and we saw a few ways to fix
      the race completely:
      
      a) We guarantee that i_mutex lock and i_alloc_sem write lock are both hold 
      whenever vmtruncate() is called. The i_mutex lock prevents any new write
      requests from entering writeback and the i_alloc_sem prevents the race
      from ext4_page_mkwrite(). Currently we hold both locks if vmtruncate()
      is called from do_truncate(), which is probably the most common case.
      However, there are places where we may call vmtruncate() without holding
      either i_mutex or i_alloc_sem. I would like to ask for other people's
      opinions on what locks are expected to be held before calling vmtruncate().
      There seems a disagreement among the callers of that function.
      
      b) We change the ext4 write path so that we change the extent tree to contain 
      the newly allocated blocks and update i_size both at the same time --- when 
      the write of the data blocks is completed.
      
      c) We add some additional locking to synchronize vmtruncate() and 
      ext4_end_io_work(). This approach may have performance implications so we
      need to be careful.
      
      All of the above proposals may require more substantial changes, so
      we may consider to take the following patch as a bandaid.
      Signed-off-by: default avatarJiaying Zhang <jiayingz@google.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      3889fd57
    • Theodore Ts'o's avatar
      ext4: drop ec_type from the ext4_ext_cache structure · b05e6ae5
      Theodore Ts'o authored
      
      
      We can encode the ec_type information by using ee_len == 0 to denote
      EXT4_EXT_CACHE_NO, ee_start == 0 to denote EXT4_EXT_CACHE_GAP, and if
      neither is true, then the cache type must be EXT4_EXT_CACHE_EXTENT.
      This allows us to reduce the size of ext4_ext_inode by another 8
      bytes.  (ec_type is 4 bytes, plus another 4 bytes of padding)
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      b05e6ae5
    • Theodore Ts'o's avatar
      ext4: use ext4_lblk_t instead of sector_t for logical blocks · 01f49d0b
      Theodore Ts'o authored
      
      
      This fixes a number of places where we used sector_t instead of
      ext4_lblk_t for logical blocks, which for ext4 are still 32-bit data
      types.  No point wasting space in the ext4_inode_info structure, and
      requiring 64-bit arithmetic on 32-bit systems, when it isn't
      necessary.
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      01f49d0b
    • Kazuya Mio's avatar
      ext4: fix 32bit overflow in ext4_ext_find_goal() · ad4fb9ca
      Kazuya Mio authored
      
      
      ext4_ext_find_goal() returns an ideal physical block number that the block
      allocator tries to allocate first. However, if a required file offset is
      smaller than the existing extent's one, ext4_ext_find_goal() returns
      a wrong block number because it may overflow at
      "block - le32_to_cpu(ex->ee_block)". This patch fixes the problem.
      
      ext4_ext_find_goal() will also return a wrong block number in case
      a file offset of the existing extent is too big. In this case,
      the ideal physical block number is fixed in ext4_mb_initialize_context(),
      so it's no problem.
      
      reproduce:
      # dd if=/dev/zero of=/mnt/mp1/tmp bs=127M count=1 oflag=sync
      # dd if=/dev/zero of=/mnt/mp1/file bs=512K count=1 seek=1 oflag=sync
      # filefrag -v /mnt/mp1/file
      Filesystem type is: ef53
      File size of /mnt/mp1/file is 1048576 (256 blocks, blocksize 4096)
       ext logical physical expected length flags
         0     128    67456             128 eof
      /mnt/mp1/file: 2 extents found
      # rm -rf /mnt/mp1/tmp
      # echo $((512*4096)) > /sys/fs/ext4/loop0/mb_stream_req
      # dd if=/dev/zero of=/mnt/mp1/file bs=512K count=1 oflag=sync conv=notrunc
      
      result (linux-2.6.37-rc2 + ext4 patch queue):
      # filefrag -v /mnt/mp1/file
      Filesystem type is: ef53
      File size of /mnt/mp1/file is 1048576 (256 blocks, blocksize 4096)
       ext logical physical expected length flags
         0       0    33280             128 
         1     128    67456    33407    128 eof
      /mnt/mp1/file: 2 extents found
      
      result(apply this patch):
      # filefrag -v /mnt/mp1/file
      Filesystem type is: ef53
      File size of /mnt/mp1/file is 1048576 (256 blocks, blocksize 4096)
       ext logical physical expected length flags
         0       0    66560             128 
         1     128    67456    66687    128 eof
      /mnt/mp1/file: 2 extents found
      Signed-off-by: default avatarKazuya Mio <k-mio@sx.jp.nec.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      ad4fb9ca
  2. 27 Oct, 2010 6 commits
  3. 27 Jul, 2010 1 commit
  4. 16 Jun, 2010 1 commit
  5. 14 Jun, 2010 1 commit
  6. 17 May, 2010 1 commit
  7. 16 May, 2010 9 commits
  8. 11 May, 2010 1 commit
  9. 03 Apr, 2010 1 commit
  10. 03 Mar, 2010 2 commits
  11. 02 Mar, 2010 1 commit
  12. 04 Mar, 2010 1 commit
    • Jiaying Zhang's avatar
      ext4: use ext4_get_block_write in buffer write · 744692dc
      Jiaying Zhang authored
      
      
      Allocate uninitialized extent before ext4 buffer write and
      convert the extent to initialized after io completes.
      The purpose is to make sure an extent can only be marked
      initialized after it has been written with new data so
      we can safely drop the i_mutex lock in ext4 DIO read without
      exposing stale data. This helps to improve multi-thread DIO
      read performance on high-speed disks.
      
      Skip the nobh and data=journal mount cases to make things simple for now.
      Signed-off-by: default avatarJiaying Zhang <jiayingz@google.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      744692dc
  13. 02 Mar, 2010 1 commit
  14. 24 Feb, 2010 1 commit
  15. 04 Mar, 2010 1 commit
  16. 15 Feb, 2010 1 commit
  17. 24 Jan, 2010 1 commit
    • Theodore Ts'o's avatar
      ext4: Use bitops to read/modify EXT4_I(inode)->i_state · 19f5fb7a
      Theodore Ts'o authored
      
      
      At several places we modify EXT4_I(inode)->i_state without holding
      i_mutex (ext4_release_file, ext4_bmap, ext4_journalled_writepage,
      ext4_do_update_inode, ...). These modifications are racy and we can
      lose updates to i_state. So convert handling of i_state to use bitops
      which are atomic.
      
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      19f5fb7a
  18. 14 Jan, 2010 1 commit
  19. 25 Jan, 2010 1 commit
  20. 01 Jan, 2010 1 commit
    • Theodore Ts'o's avatar
      ext4: Calculate metadata requirements more accurately · 9d0be502
      Theodore Ts'o authored
      In the past, ext4_calc_metadata_amount(), and its sub-functions
      ext4_ext_calc_metadata_amount() and ext4_indirect_calc_metadata_amount()
      badly over-estimated the number of metadata blocks that might be
      required for delayed allocation blocks.  This didn't matter as much
      when functions which managed the reserved metadata blocks were more
      aggressive about dropping reserved metadata blocks as delayed
      allocation blocks were written, but unfortunately they were too
      aggressive.  This was fixed in commit 0637c6f4
      
      , but as a result the
      over-estimation by ext4_calc_metadata_amount() would lead to reserving
      2-3 times the number of pending delayed allocation blocks as
      potentially required metadata blocks.  So if there are 1 megabytes of
      blocks which have been not yet been allocation, up to 3 megabytes of
      space would get reserved out of the user's quota and from the file
      system free space pool until all of the inode's data blocks have been
      allocated.
      
      This commit addresses this problem by much more accurately estimating
      the number of metadata blocks that will be required.  It will still
      somewhat over-estimate the number of blocks needed, since it must make
      a worst case estimate not knowing which physical blocks will be
      needed, but it is much more accurate than before.
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      9d0be502
  21. 29 Dec, 2009 1 commit
  22. 14 Dec, 2009 1 commit