1. 07 5月, 2013 1 次提交
    • J
      Btrfs: add a incompatible format change for smaller metadata extent refs · 3173a18f
      Josef Bacik 提交于
      We currently store the first key of the tree block inside the reference for the
      tree block in the extent tree.  This takes up quite a bit of space.  Make a new
      key type for metadata which holds the level as the offset and completely removes
      storing the btrfs_tree_block_info inside the extent ref.  This reduces the size
      from 51 bytes to 33 bytes per extent reference for each tree block.  In practice
      this results in a 30-35% decrease in the size of our extent tree, which means we
      COW less and can keep more of the extent tree in memory which makes our heavy
      metadata operations go much faster.  This is not an automatic format change, you
      must enable it at mkfs time or with btrfstune.  This patch deals with having
      metadata stored as either the old format or the new format so it is easy to
      convert.  Thanks,
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      3173a18f
  2. 22 3月, 2013 1 次提交
    • J
      Btrfs: fix locking on ROOT_REPLACE operations in tree mod log · d9abbf1c
      Jan Schmidt 提交于
      To resolve backrefs, ROOT_REPLACE operations in the tree mod log are
      required to be tied to at least one KEY_REMOVE_WHILE_FREEING operation.
      Therefore, those operations must be enclosed by tree_mod_log_write_lock()
      and tree_mod_log_write_unlock() calls.
      
      Those calls are private to the tree_mod_log_* functions, which means that
      removal of the elements of an old root node must be logged from
      tree_mod_log_insert_root. This partly reverts and corrects commit ba1bfbd5
      (Btrfs: fix a tree mod logging issue for root replacement operations).
      
      This fixes the brand-new version of xfstest 276 as of commit cfe73f71.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJan Schmidt <list.btrfs@jan-o-sch.net>
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      d9abbf1c
  3. 21 2月, 2013 2 次提交
  4. 15 2月, 2013 1 次提交
  5. 19 12月, 2012 2 次提交
  6. 17 12月, 2012 5 次提交
  7. 13 12月, 2012 2 次提交
  8. 12 12月, 2012 4 次提交
  9. 26 10月, 2012 1 次提交
  10. 24 10月, 2012 4 次提交
  11. 23 10月, 2012 2 次提交
  12. 09 10月, 2012 1 次提交
  13. 02 10月, 2012 1 次提交
    • C
      Btrfs: fix btrfs send for inline items and compression · 74dd17fb
      Chris Mason 提交于
      The btrfs send code was assuming the offset of the file item into the
      extent translated to bytes on disk.  If we're compressed, this isn't
      true, and so it was off into extents owned by other files.
      
      It was also improperly handling inline extents.  This solves a crash
      where we may have gone past the end of the file extent item by not
      testing early enough for an inline extent.  It also solves problems
      where we have a whole between the end of the inline item and the start
      of the full extent.
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      74dd17fb
  14. 29 8月, 2012 2 次提交
    • C
      Btrfs: don't run __tree_mod_log_free_eb on leaves · b12a3b1e
      Chris Mason 提交于
      When we split a leaf, we may end up inserting a new root on top of that
      leaf.  The reflog code was incorrectly assuming the old root was always
      a node.  This makes sure we skip over leaves.
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      b12a3b1e
    • A
      Btrfs: fix deadlock in wait_for_more_refs · 1fa11e26
      Arne Jansen 提交于
      Commit a168650c introduced a waiting mechanism to prevent busy waiting in
      btrfs_run_delayed_refs. This can deadlock with btrfs_run_ordered_operations,
      where a tree_mod_seq is held while waiting for the io to complete, while
      the end_io calls btrfs_run_delayed_refs.
      This whole mechanism is unnecessary. If not enough runnable refs are
      available to satisfy count, just return as count is more like a guideline
      than a strict requirement.
      In case we have to run all refs, commit transaction makes sure that no
      other threads are working in the transaction anymore, so we just assert
      here that no refs are blocked.
      Signed-off-by: NArne Jansen <sensille@gmx.net>
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      1fa11e26
  15. 26 7月, 2012 1 次提交
  16. 25 7月, 2012 1 次提交
  17. 24 7月, 2012 1 次提交
  18. 10 7月, 2012 3 次提交
  19. 27 6月, 2012 4 次提交
    • J
      Btrfs: resolve tree mod log locking issue in btrfs_next_leaf · d42244a0
      Jan Schmidt 提交于
      With the tree mod log, we may end up with two roots (the current root and a
      rewinded version of it) both pointing to two leaves, l1 and l2, of which l2
      had already been cow-ed in the current transaction. If we don't rewind any
      tree blocks, we cannot have two roots both pointing to an already cowed tree
      block.
      
      Now there is btrfs_next_leaf, which has a leaf locked and wants a lock on
      the next (right) leaf. And there is push_leaf_left, which has a (cowed!)
      leaf locked and wants a lock on the previous (left) leaf.
      
      In order to solve this dead lock situation, we use try_lock in
      btrfs_next_leaf (only in case it's called with a tree mod log time_seq
      paramter) and if we fail to get a lock on the next leaf, we give up our lock
      on the current leaf and retry from the very beginning.
      Signed-off-by: NJan Schmidt <list.btrfs@jan-o-sch.net>
      d42244a0
    • J
      Btrfs: fix tree mod log rewind of ADD operations · 19956c7e
      Jan Schmidt 提交于
      When a MOD_LOG_KEY_ADD operation is rewinded, we remove the key from the
      tree block. If its not the last key, removal involves a move operation.
      This move operation was explicitly done before this commit.
      
      However, at insertion time, there's a move operation before the actual
      addition to make room for the new key, which is recorded in the tree mod
      log as well. This means, we must drop the move operation when rewinding the
      add operation, because the next operation we'll be rewinding will be the
      corresponding MOD_LOG_MOVE_KEYS operation.
      Signed-off-by: NJan Schmidt <list.btrfs@jan-o-sch.net>
      19956c7e
    • J
      Btrfs: always put insert_ptr modifications into the tree mod log · c3e06965
      Jan Schmidt 提交于
      Several callers of insert_ptr set the tree_mod_log parameter to 0 to avoid
      addition to the tree mod log. In fact, we need all of those operations. This
      commit simply removes the additional parameter and makes addition to the
      tree mod log unconditional.
      Signed-off-by: NJan Schmidt <list.btrfs@jan-o-sch.net>
      c3e06965
    • J
      Btrfs: fix tree mod log for root replacements at leaf level · 28da9fb4
      Jan Schmidt 提交于
      For the tree mod log, we don't log any operations at leaf level. If the root
      is at the leaf level (i.e. the tree consists only of the root), then
      __tree_mod_log_oldest_root will find a ROOT_REPLACE operation in the log
      (because we always log that one no matter which level), but no other
      operations.
      
      With this patch __tree_mod_log_oldest_root exits cleanly instead of
      BUGging in this situation. get_old_root checks if its really a root at leaf
      level in case we don't have any operations and WARNs if this assumption
      breaks.
      Signed-off-by: NJan Schmidt <list.btrfs@jan-o-sch.net>
      28da9fb4
  20. 16 6月, 2012 1 次提交