Skip to content

Commit

Permalink
Btrfs: empty_size allocation fixes again
Browse files Browse the repository at this point in the history
The allocator wasn't catching all of the cases where it needed to do
extra loops because the check to enforce them wasn't happening early
enough.

When the allocator decided to increase the size of the allocation
for metadata clustering, it wasn't always setting the empty_size to
include the extra (optional) bytes.  This also fixes the empty_size field
to be correct.

Signed-off-by: Chris Mason <chris.mason@oracle.com>
  • Loading branch information
Chris Mason committed Nov 10, 2008
1 parent 240d5d4 commit 8a1413a
Showing 1 changed file with 4 additions and 3 deletions.
7 changes: 4 additions & 3 deletions fs/btrfs/extent-tree.c
Original file line number Diff line number Diff line change
Expand Up @@ -2174,6 +2174,9 @@ static int noinline find_free_extent(struct btrfs_trans_handle *trans,
* group thats not of the proper type, while looping this
* should never happen
*/
if (empty_size)
extra_loop = 1;

if (!block_group)
goto new_group_no_lock;

Expand All @@ -2192,9 +2195,6 @@ static int noinline find_free_extent(struct btrfs_trans_handle *trans,

free_space = btrfs_find_free_space(block_group, search_start,
total_needed);
if (empty_size)
extra_loop = 1;

if (free_space) {
u64 start = block_group->key.objectid;
u64 end = block_group->key.objectid +
Expand All @@ -2212,6 +2212,7 @@ static int noinline find_free_extent(struct btrfs_trans_handle *trans,

if (last_wanted && search_start != last_wanted) {
total_needed += empty_cluster;
empty_size += empty_cluster;
last_wanted = 0;
/*
* if search_start is still in this block group
Expand Down

0 comments on commit 8a1413a

Please sign in to comment.