1. 10 Jun, 2011 2 commits
    • Sage Weil's avatar
      Btrfs: clear current->journal_info on async transaction commit · 38e88054
      Sage Weil authored
      Normally current->jouranl_info is cleared by commit_transaction.  For an
      async snap or subvol creation, though, it runs in a work queue.  Clear
      it in btrfs_commit_transaction_async() to avoid leaking a non-NULL
      journal_info when we return to userspace.  When the actual commit runs in
      the other thread it won't care that it's current->journal_info is already
      NULL.
      Signed-off-by: default avatarSage Weil <sage@newdream.net>
      Tested-by: default avatarJim Schutt <jaschut@sandia.gov>
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      38e88054
    • Chris Mason's avatar
      Btrfs: make sure to recheck for bitmaps in clusters · 38e87880
      Chris Mason authored
      Josef recently changed the free extent cache to look in
      the block group cluster for any bitmaps before trying to
      add a new bitmap for the same offset.  This avoids BUG_ON()s due
      covering duplicate ranges.
      
      But it didn't go quite far enough.  A given free range might span
      between one or more bitmaps or free space entries.  The code has
      looping to cover this, but it doesn't check for clustered bitmaps
      every time.
      
      This shuffles our gotos to check for a bitmap in the cluster
      for every new bitmap entry we try to add.
      Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      38e87880
  2. 09 Jun, 2011 2 commits
  3. 08 Jun, 2011 6 commits
    • Josef Bacik's avatar
      Btrfs: fix duplicate checking logic · f6a39829
      Josef Bacik authored
      When merging my code into the integration test the second check for duplicate
      entries got screwed up.  This patch fixes it by dropping ret2 and just using ret
      for the return value, and checking if we got an error before adding the bitmap
      to the local list.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      f6a39829
    • Josef Bacik's avatar
      Btrfs: fix the allocator loop logic · 723bda20
      Josef Bacik authored
      I was testing with empty_cluster = 0 to try and reproduce a problem and kept
      hitting early enospc panics.  This was because our loop logic was a little
      confused.  So this is what I did
      
      1) Make the loop variable the ultimate decider on wether we should loop again
      isntead of checking to see if we had an uncached bg, empty size or empty
      cluster.
      
      2) Increment loop before checking to see what we are on to make the loop
      definitions make more sense.
      
      3) If we are on the chunk alloc loop don't set empty_size/empty_cluster to 0
      unless we didn't actually allocate a chunk.  If we did allocate a chunk we
      should be able to easily setup a new cluster so clearing
      empty_size/empty_cluster makes us less efficient.
      
      This kept me from hitting panics while trying to reproduce the other problem.
      Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      723bda20
    • Josef Bacik's avatar
      Btrfs: fix bitmap regression · 2cdc342c
      Josef Bacik authored
      In cleaning up the clustering code I accidently introduced a regression by
      adding bitmap entries to the cluster rb tree.  The problem is if we've maxed out
      the number of bitmaps we can have for the block group we can only add free space
      to the bitmaps, but since the bitmap is on the cluster we can't find it and we
      try to create another one.  This would result in a panic because the total
      bitmaps was bigger than the max bitmaps that were allowed.  This patch fixes
      this by checking to see if we have a cluster, and then looking at the cluster rb
      tree to see if it has a bitmap entry and if it does and that space belongs to
      that bitmap, go ahead and add it to that bitmap.
      
      I could hit this panic every time with an fs_mark test within a couple of
      minutes.  With this patch I no longer hit the panic and fs_mark goes to
      completion.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      2cdc342c
    • Josef Bacik's avatar
      Btrfs: don't commit the transaction if we dont have enough pinned bytes · f2bb8f5c
      Josef Bacik authored
      I noticed when running an enospc test that we would get stuck committing the
      transaction in check_data_space even though we truly didn't have enough space.
      So check to see if bytes_pinned is bigger than num_bytes, if it's not don't
      commit the transaction.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      f2bb8f5c
    • Josef Bacik's avatar
      Btrfs: noinline the cluster searching functions · 3de85bb9
      Josef Bacik authored
      When profiling the find cluster code it's hard to tell where we are spending our
      time because the bitmap and non-bitmap functions get inlined by the compiler, so
      make that not happen.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      3de85bb9
    • Josef Bacik's avatar
      Btrfs: cache bitmaps when searching for a cluster · 86d4a77b
      Josef Bacik authored
      If we are looking for a cluster in a particularly sparse or fragmented block
      group, we will do a lot of looping through the free space tree looking for
      various things, and if we need to look at bitmaps we will endup doing the whole
      dance twice.  So instead add the bitmap entries to a temporary list so if we
      have to do the bitmap search we can just look through the list of entries we've
      found quickly instead of having to loop through the entire tree again.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      86d4a77b
  4. 04 Jun, 2011 11 commits
  5. 28 May, 2011 1 commit
  6. 27 May, 2011 1 commit
  7. 26 May, 2011 4 commits
  8. 23 May, 2011 13 commits