1. 24 May, 2011 6 commits
    • Lukas Czerner's avatar
      ext4: only load buddy bitmap in ext4_trim_fs() when it is needed · 78944086
      Lukas Czerner authored
      Currently we are loading buddy ext4_mb_load_buddy() for every block
      group we are going through in ext4_trim_fs() in many cases just to find
      out that there is not enough space to be bothered with. As Amir Goldstein
      suggested we can use bb_free information directly from ext4_group_info.
      
      This commit removes ext4_mb_load_buddy() from ext4_trim_fs() and rather
      get the ext4_group_info via ext4_get_group_info() and use the bb_free
      information directly from that. This avoids unnecessary call to load
      buddy in the case the group does not have enough free space to trim.
      Loading buddy is now moved to ext4_trim_all_free().
      
      Tested by me with xfstests 251.
      Signed-off-by: default avatarLukas Czerner <lczerner@redhat.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      78944086
    • Eryu Guan's avatar
      jbd2: Fix comment to match the code in jbd2__journal_start() · c867516d
      Eryu Guan authored
      jbd2__journal_start() returns an ERR_PTR() value rather than NULL on
      failure.
      Signed-off-by: default avatarEryu Guan <guaneryu@gmail.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      c867516d
    • Jan Kara's avatar
      ext4: fix waiting and sending of a barrier in ext4_sync_file() · 93628ffb
      Jan Kara authored
      jbd2_log_start_commit() returns 1 only when we really start a
      transaction.  But we also need to wait for a transaction when the
      commit is already running.  Fix this problem by waiting for
      transaction commit unconditionally (which is just a quick check if the
      transaction is already committed).
      
      Also we have to be more careful with sending of a barrier because when
      transaction is being committed in parallel to ext4_sync_file()
      running, we cannot be sure that the barrier the journalling code sends
      happens after we wrote all the data for fsync (note that not every
      data writeout needs to trigger metadata changes thus commit of some
      metadata changes can be running while other data is still written
      out). So use jbd2_will_send_data_barrier() helper to detect the common
      cases when we can be sure barrier will be issued by the commit code
      and issue the barrier ourselves in the remaining cases.
      Reported-by: default avatarEdward Goggin <egoggin@vmware.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      93628ffb
    • Jan Kara's avatar
      jbd2: Add function jbd2_trans_will_send_data_barrier() · bbd2be36
      Jan Kara authored
      Provide a function which returns whether a transaction with given tid
      will send a flush to the filesystem device.  The function will be used
      by ext4 to detect whether fsync needs to send a separate flush or not.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      bbd2be36
    • Jan Kara's avatar
      jbd2: fix sending of data flush on journal commit · 81be12c8
      Jan Kara authored
      
      In data=ordered mode, it's theoretically possible (however rare) that
      an inode is filed to transaction's t_inode_list and a flusher thread
      writes all the data and inode is reclaimed before the transaction
      starts to commit.  In such a case, we could erroneously omit sending a
      flush to file system device when it is different from the journal
      device (because data can still be in disk cache only).
      
      Fix the problem by setting a flag in a transaction when some inode is added
      to it and then send disk flush in the commit code when the flag is set.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      81be12c8
    • Yongqiang Yang's avatar
      ext4: fix ext4_ext_fiemap_cb() to handle blocks before request range correctly · b221349f
      Yongqiang Yang authored
      To get delayed-extent information, ext4_ext_fiemap_cb() looks up
      pagecache, it thus collects information starting from a page's
      head block.
      
      If blocksize < pagesize, the beginning blocks of a page may lies
      before the request range. So ext4_ext_fiemap_cb() should proceed
      ignoring them, because they has been handled before. If no mapped
      buffer in the range is found in the 1st page, we need to look up
      the 2nd page, otherwise delayed-extents after a hole will be ignored.
      
      Without this patch, xfstests 225 will hung on ext4 with 1K block.
      Reported-by: default avatarAmir Goldstein <amir73il@users.sourceforge.net>
      Signed-off-by: default avatarYongqiang Yang <xiaoqiangnk@gmail.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      b221349f
  2. 23 May, 2011 5 commits
  3. 22 May, 2011 1 commit
    • Theodore Ts'o's avatar
      ext4: don't show mount options in /proc/mounts if there is no journal · 373cd5c5
      Theodore Ts'o authored
      After creating an ext4 file system without a journal:
      
        # mke2fs -t ext4 -O ^has_journal /dev/sda
        # mount -t ext4 /dev/sda /test
      
      the /proc/mounts will show:
      "/dev/sda /test ext4 rw,relatime,user_xattr,acl,barrier=1,data=writeback 0 0"
      which can fool users into thinking that the fs is using writeback mode.
      
      So don't set the writeback option when the journal has not been
      enabled; we don't depend on the writeback option being set, since
      ext4_should_writeback_data() in ext4_jbd2.h tests to see if the
      journal is not present before returning true.
      Reported-by: default avatarRobin Dong <sanbai@taobao.com>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      
      373cd5c5
  4. 20 May, 2011 4 commits
  5. 18 May, 2011 3 commits
  6. 16 May, 2011 2 commits
  7. 15 May, 2011 1 commit
  8. 10 May, 2011 4 commits
  9. 09 May, 2011 6 commits
  10. 08 May, 2011 2 commits
  11. 03 May, 2011 6 commits