An error occurred fetching the project authors.
  1. 11 Dec, 2012 3 commits
  2. 25 Oct, 2012 1 commit
  3. 24 Oct, 2012 4 commits
  4. 23 Oct, 2012 2 commits
  5. 09 Oct, 2012 1 commit
  6. 01 Oct, 2012 1 commit
    • Chris Mason's avatar
      Btrfs: fix btrfs send for inline items and compression · 74dd17fb
      Chris Mason authored
      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: default avatarChris Mason <chris.mason@fusionio.com>
      74dd17fb
  7. 28 Aug, 2012 2 commits
    • Chris Mason's avatar
      Btrfs: don't run __tree_mod_log_free_eb on leaves · b12a3b1e
      Chris Mason authored
      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: default avatarChris Mason <chris.mason@fusionio.com>
      b12a3b1e
    • Arne Jansen's avatar
      Btrfs: fix deadlock in wait_for_more_refs · 1fa11e26
      Arne Jansen authored
      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: default avatarArne Jansen <sensille@gmx.net>
      Signed-off-by: default avatarChris Mason <chris.mason@fusionio.com>
      1fa11e26
  8. 25 Jul, 2012 2 commits
  9. 23 Jul, 2012 1 commit
  10. 10 Jul, 2012 3 commits
  11. 27 Jun, 2012 4 commits
    • Jan Schmidt's avatar
      Btrfs: resolve tree mod log locking issue in btrfs_next_leaf · d42244a0
      Jan Schmidt authored
      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: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      d42244a0
    • Jan Schmidt's avatar
      Btrfs: fix tree mod log rewind of ADD operations · 19956c7e
      Jan Schmidt authored
      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: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      19956c7e
    • Jan Schmidt's avatar
      Btrfs: always put insert_ptr modifications into the tree mod log · c3e06965
      Jan Schmidt authored
      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: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      c3e06965
    • Jan Schmidt's avatar
      Btrfs: fix tree mod log for root replacements at leaf level · 28da9fb4
      Jan Schmidt authored
      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: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      28da9fb4
  12. 16 Jun, 2012 1 commit
  13. 14 Jun, 2012 4 commits
    • Jan Schmidt's avatar
      Btrfs: fix race in tree mod log addition · 3310c36e
      Jan Schmidt authored
      When adding to the tree modification log, we grab two locks at different
      stages. We must not drop the outer lock until we're done with section
      protected by the inner lock. This moves the unlock call for the outer lock
      to the appropriate position.
      Signed-off-by: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      3310c36e
    • Jan Schmidt's avatar
      Btrfs: add btrfs_next_old_leaf · 3d7806ec
      Jan Schmidt authored
      To make sense of the tree mod log, the backref walker not only needs
      btrfs_search_old_slot, but it also called btrfs_next_leaf, which in turn was
      calling btrfs_search_slot. This obviously didn't give the correct result.
      
      This commit adds btrfs_next_old_leaf, a drop-in replacement for
      btrfs_next_leaf with a time_seq parameter. If it is zero, it behaves exactly
      like btrfs_next_leaf. If it is non-zero, it will use btrfs_search_old_slot
      with this time_seq parameter.
      Signed-off-by: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      3d7806ec
    • Jan Schmidt's avatar
      Btrfs: fix return value for __tree_mod_log_oldest_root · a95236d9
      Jan Schmidt authored
      In __tree_mod_log_oldest_root() we must return the found operation even if
      it's not a ROOT_REPLACE operation. Otherwise, the caller assumes that there
      are no operations to be rewinded and returns immediately.
      
      The code in the caller is modified to improve readability.
      Signed-off-by: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      a95236d9
    • Jan Schmidt's avatar
      Btrfs: use btrfs_read_lock_root_node in get_old_root · 8ba97a15
      Jan Schmidt authored
      get_old_root could race with root node updates because we weren't locking
      the node early enough. Use btrfs_read_lock_root_node to grab the root locked
      in the very beginning and release the lock as soon as possible (just like
      btrfs_search_slot does).
      Signed-off-by: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      8ba97a15
  14. 04 Jun, 2012 1 commit
  15. 31 May, 2012 4 commits
  16. 30 May, 2012 5 commits
  17. 26 May, 2012 1 commit