1. 02 10月, 2012 2 次提交
    • J
      Btrfs: remove unused hint byte argument for btrfs_drop_extents · 2671485d
      Josef Bacik 提交于
      I audited all users of btrfs_drop_extents and found that nobody actually uses
      the hint_byte argument.  I'm sure it was used for something at some point but
      it's not used now, and the way the pinning works the disk bytenr would never be
      immediately useful anyway so lets just remove it.  Thanks,
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      2671485d
    • J
      Btrfs: turbo charge fsync · 5dc562c5
      Josef Bacik 提交于
      At least for the vm workload.  Currently on fsync we will
      
      1) Truncate all items in the log tree for the given inode if they exist
      
      and
      
      2) Copy all items for a given inode into the log
      
      The problem with this is that for things like VMs you can have lots of
      extents from the fragmented writing behavior, and worst yet you may have
      only modified a few extents, not the entire thing.  This patch fixes this
      problem by tracking which transid modified our extent, and then when we do
      the tree logging we find all of the extents we've modified in our current
      transaction, sort them and commit them.  We also only truncate up to the
      xattrs of the inode and copy that stuff in normally, and then just drop any
      extents in the range we have that exist in the log already.  Here are some
      numbers of a 50 meg fio job that does random writes and fsync()s after every
      write
      
      		Original	Patched
      SATA drive	82KB/s		140KB/s
      Fusion drive	431KB/s		2532KB/s
      
      So around 2-6 times faster depending on your hardware.  There are a few
      corner cases, for example if you truncate at all we have to do it the old
      way since there is no way to be sure what is in the log is ok.  This
      probably could be done smarter, but if you write-fsync-truncate-write-fsync
      you deserve what you get.  All this work is in RAM of course so if your
      inode gets evicted from cache and you read it in and fsync it we'll do it
      the slow way if we are still in the same transaction that we last modified
      the inode in.
      
      The biggest cool part of this is that it requires no changes to the recovery
      code, so if you fsync with this patch and crash and load an old kernel, it
      will run the recovery and be a-ok.  I have tested this pretty thoroughly
      with an fsync tester and everything comes back fine, as well as xfstests.
      Thanks,
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      5dc562c5
  2. 29 8月, 2012 1 次提交
  3. 09 8月, 2012 1 次提交
  4. 31 7月, 2012 1 次提交
  5. 26 7月, 2012 3 次提交
  6. 25 7月, 2012 1 次提交
    • D
      btrfs: allow cross-subvolume file clone · 362a20c5
      David Sterba 提交于
      Lift the EXDEV condition and allow different root trees for files being
      cloned, then pass source inode's root when searching for extents.
      Cloning is not allowed to cross vfsmounts, ie. when two subvolumes from
      one filesystem are mounted separately.
      Signed-off-by: NDavid Sterba <dsterba@suse.cz>
      362a20c5
  7. 24 7月, 2012 6 次提交
  8. 23 7月, 2012 1 次提交
  9. 12 7月, 2012 2 次提交
  10. 16 6月, 2012 1 次提交
  11. 15 6月, 2012 3 次提交
    • L
      Btrfs: do not resize a seeding device · 4e42ae1b
      Liu Bo 提交于
      Seeding devices are not supposed to change any more.
      Signed-off-by: NLiu Bo <liubo2009@cn.fujitsu.com>
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      4e42ae1b
    • L
      Btrfs: fix defrag regression · 6c282eb4
      Li Zefan 提交于
      If a file has 3 small extents:
      
      | ext1 | ext2 | ext3 |
      
      Running "btrfs fi defrag" will only defrag the last two extents, if those
      extent mappings hasn't been read into memory from disk.
      
      This bug was introduced by commit 17ce6ef8
      ("Btrfs: add a check to decide if we should defrag the range")
      
      The cause is, that commit looked into previous and next extents using
      lookup_extent_mapping() only.
      
      While at it, remove the code that checks the previous extent, since
      it's sufficient to check the next extent.
      Signed-off-by: NLi Zefan <lizefan@huawei.com>
      6c282eb4
    • J
      Btrfs: use rcu to protect device->name · 606686ee
      Josef Bacik 提交于
      Al pointed out that we can just toss out the old name on a device and add a
      new one arbitrarily, so anybody who uses device->name in printk could
      possibly use free'd memory.  Instead of adding locking around all of this he
      suggested doing it with RCU, so I've introduced a struct rcu_string that
      does just that and have gone through and protected all accesses to
      device->name that aren't under the uuid_mutex with rcu_read_lock().  This
      protects us and I will use it for dealing with removing the device that we
      used to mount the file system in a later patch.  Thanks,
      Reviewed-by: NDavid Sterba <dsterba@suse.cz>
      Signed-off-by: NJosef Bacik <josef@redhat.com>
      606686ee
  12. 30 5月, 2012 5 次提交
  13. 26 5月, 2012 1 次提交
  14. 19 4月, 2012 1 次提交
  15. 29 3月, 2012 5 次提交
  16. 27 3月, 2012 1 次提交
    • J
      Btrfs: fix regression in scrub path resolving · 7a3ae2f8
      Jan Schmidt 提交于
      In commit 4692cf58 we introduced new backref walking code for btrfs. This
      assumes we're searching live roots, which requires a transaction context.
      While scrubbing, however, we must not join a transaction because this could
      deadlock with the commit path. Additionally, what scrub really wants to do
      is resolving a logical address in the commit root it's currently checking.
      
      This patch adds support for logical to path resolving on commit roots and
      makes scrub use that.
      Signed-off-by: NJan Schmidt <list.btrfs@jan-o-sch.net>
      7a3ae2f8
  17. 22 3月, 2012 3 次提交
  18. 23 2月, 2012 1 次提交
  19. 17 2月, 2012 1 次提交
    • M
      Btrfs: fix deadlock on page lock when doing auto-defragment · 600a45e1
      Miao Xie 提交于
      When I ran xfstests circularly on a auto-defragment btrfs, the deadlock
      happened.
      
      Steps to reproduce:
      [tty0]
       # export MOUNT_OPTIONS="-o autodefrag"
       # export TEST_DEV=<partition1>
       # export TEST_DIR=<mountpoint1>
       # export SCRATCH_DEV=<partition2>
       # export SCRATCH_MNT=<mountpoint2>
       # while [ 1 ]
       > do
       > ./check 091 127 263
       > sleep 1
       > done
      [tty1]
       # while [ 1 ]
       > do
       > echo 3 > /proc/sys/vm/drop_caches
       > done
      
      Several hours later, the test processes will hang on, and the deadlock will
      happen on page lock.
      
      The reason is that:
        Auto defrag task		Flush thread			Test task
      				btrfs_writepages()
      				  add ordered extent
      				  (including page 1, 2)
      				  set page 1 writeback
      				  set page 2 writeback
      				endio_fn()
      				  end page 2 writeback
      								release page 2
      lock page 1
      alloc and lock page 2
      page 2 is not uptodate
        btrfs_readpage()
          start ordered extent()
          btrfs_writepages()
            try  to lock page 1
      
      so deadlock happens.
      
      Fix this bug by unlocking the page which is in writeback, and re-locking it
      after the writeback end.
      Signed-off-by: NMiao Xie <miax@cn.fujitsu.com>
      600a45e1