1. 26 May, 2012 5 commits
    • Jan Schmidt's avatar
      Btrfs: don't set for_cow parameter for tree block functions · 5581a51a
      Jan Schmidt authored
      Three callers of btrfs_free_tree_block or btrfs_alloc_tree_block passed
      parameter for_cow = 1. In fact, these two functions should never mark
      their tree modification operations as for_cow, because they can change
      the number of blocks referenced by a tree.
      
      Hence, we remove the extra for_cow parameter from these functions and
      make them pass a zero down.
      Signed-off-by: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      5581a51a
    • Jan Schmidt's avatar
      Btrfs: look into the extent during find_all_leafs · 976b1908
      Jan Schmidt authored
      Before this patch we called find_all_leafs for a data extent, then called
      find_all_roots and then looked into the extent to grab the information
      we were seeking. This was done without holding the leaves locked to avoid
      deadlocks. However, this can obviouly race with concurrent tree
      modifications.
      
      Instead, we now look into the extent while we're holding the lock during
      find_all_leafs and store this information together with the leaf list.
      Signed-off-by: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      976b1908
    • Jan Schmidt's avatar
      Btrfs: bugfix: ignore the wrong key for indirect tree block backrefs · d5c88b73
      Jan Schmidt authored
      The key we store with a tree block backref is only a hint. It is set when
      the ref is created and can remain correct for a long time. As the tree is
      rebalanced, however, eventually the key no longer points to the correct
      destination.
      
      With this patch, we change find_parent_nodes to no longer add keys unless it
      knows for sure they're correct (e.g. because they're for an extent data
      backref). Then when we later encounter a backref ref with no parent and no
      key set, we grab the block and take the first key from the block itself.
      Signed-off-by: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      d5c88b73
    • Jan Schmidt's avatar
      Btrfs: bugfix in btrfs_find_parent_nodes · dadcaf78
      Jan Schmidt authored
      That one has been around since the addition of backref.c. Due to the way we
      calculate our slot numbers, after adding inline refs we're missing one keyed
      ref unless it's located at the beginning of a new leaf.
      Reported-by: default avatarAlexander Block <ablock84@googlemail.com>
      Signed-off-by: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      dadcaf78
    • Jan Schmidt's avatar
      Btrfs: ulist realloc bugfix · cd1b413c
      Jan Schmidt authored
      ulist_next gets the pointer to the previously returned element to find the
      next element from there. However, when we call ulist_add while iteration
      with ulist_next is in progress (ulist explicitly supports this), we can
      realloc the ulist internal memory, which makes the pointer to the previous
      element useless.
      
      Instead, we now use an iterator parameter that's independent from the
      internal pointers.
      Reported-by: default avatarAlexander Block <ablock84@googlemail.com>
      Signed-off-by: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      cd1b413c
  2. 06 May, 2012 1 commit
    • Chris Mason's avatar
      Btrfs: avoid sleeping in verify_parent_transid while atomic · b9fab919
      Chris Mason authored
      verify_parent_transid needs to lock the extent range to make
      sure no IO is underway, and so it can safely clear the
      uptodate bits if our checks fail.
      
      But, a few callers are using it with spinlocks held.  Most
      of the time, the generation numbers are going to match, and
      we don't want to switch to a blocking lock just for the error
      case.  This adds an atomic flag to verify_parent_transid,
      and changes it to return EAGAIN if it needs to block to
      properly verifiy things.
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      b9fab919
  3. 04 May, 2012 4 commits
  4. 27 Apr, 2012 7 commits
  5. 18 Apr, 2012 19 commits
  6. 13 Apr, 2012 1 commit
  7. 12 Apr, 2012 3 commits