1. 25 Mar, 2011 2 commits
    • Josef Bacik's avatar
      Btrfs: don't allocate dip->csums when doing writes · 98bc3149
      Josef Bacik authored
      When doing direct writes we store the checksums in the ordered sum stuff in the
      ordered extent for writing them when the write completes, so we don't even use
      the dip->csums array.  So if we're writing, don't bother allocating dip->csums
      since we won't use it anyway.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      98bc3149
    • Josef Bacik's avatar
      Btrfs: cleanup how we setup free space clusters · 4e69b598
      Josef Bacik authored
      This patch makes the free space cluster refilling code a little easier to
      understand, and fixes some things with the bitmap part of it.  Currently we
      either want to refill a cluster with
      
      1) All normal extent entries (those without bitmaps)
      2) A bitmap entry with enough space
      
      The current code has this ugly jump around logic that will first try and fill up
      the cluster with extent entries and then if it can't do that it will try and
      find a bitmap to use.  So instead split this out into two functions, one that
      tries to find only normal entries, and one that tries to find bitmaps.
      
      This also fixes a suboptimal thing we would do with bitmaps.  If we used a
      bitmap we would just tell the cluster that we were pointing at a bitmap and it
      would do the tree search in the block group for that entry every time we tried
      to make an allocation.  Instead of doing that now we just add it to the clusters
      group.
      
      I tested this with my ENOSPC tests and xfstests and it survived.
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      4e69b598
  2. 21 Mar, 2011 3 commits
    • Josef Bacik's avatar
      Btrfs: don't be as aggressive about using bitmaps · 32cb0840
      Josef Bacik authored
      We have been creating bitmaps for small extents unconditionally forever.  This
      was great when testing to make sure the bitmap stuff was working, but is
      overkill normally.  So instead of always adding small chunks of free space to
      bitmaps, only start doing it if we go past half of our extent threshold.  This
      will keeps us from creating a bitmap for just one small free extent at the front
      of the block group, and will make the allocator a little faster as a result.
      Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      32cb0840
    • Josef Bacik's avatar
      Btrfs: deal with min_bytes appropriately when looking for a cluster · d0a365e8
      Josef Bacik authored
      We do all this fun stuff with min_bytes, but either don't use it in the case of
      just normal extents, or use it completely wrong in the case of bitmaps.  So fix
      this for both cases
      
      1) In the extent case, stop looking for space with window_free >= min_bytes
      instead of bytes + empty_size.
      
      2) In the bitmap case, we were looking for streches of free space that was at
      least min_bytes in size, which was not right at all.  So instead search for
      stretches of free space that are at least bytes in size (this will make a
      difference when we have > page size blocks) and then only search for min_bytes
      amount of free space.
      
      Thanks,
      Reviewed-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      d0a365e8
    • Josef Bacik's avatar
      Btrfs: check free space in block group before searching for a cluster · 7d0d2e8e
      Josef Bacik authored
      The free space cluster stuff is heavy duty, so there is no sense in going
      through the entire song and dance if there isn't enough space in the block group
      to begin with.  Thanks,
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      7d0d2e8e
  3. 17 Mar, 2011 16 commits
  4. 15 Mar, 2011 1 commit
  5. 14 Mar, 2011 18 commits