Btrfs: don't keep retrying a block group if we fail to allocate a cluster
authorJosef Bacik <josef@redhat.com>
Fri, 11 Sep 2009 20:11:20 +0000 (16:11 -0400)
committerChris Mason <chris.mason@oracle.com>
Mon, 21 Sep 2009 23:23:49 +0000 (19:23 -0400)
commit0a24325e6d8cfb150eba0aa279615ef27b5f6aec
treef0ca16ab43d87d526a1f918c7e960711256fd47f
parentba1bf4818baf68d914ef9e3b06fbea6acb674fe4
Btrfs: don't keep retrying a block group if we fail to allocate a cluster

The box can get locked up in the allocator if we happen upon a block group
under these conditions:

1) During a commit, so caching threads cannot make progress
2) Our block group currently is in the middle of being cached
3) Our block group currently has plenty of free space in it
4) Our block group is so fragmented that it ends up having no free space chunks
larger than min_bytes calculated by btrfs_find_space_cluster.

What happens is we try and do btrfs_find_space_cluster, which fails because it
is unable to find enough free space chunks that are large than min_bytes and
are close enough together.  Since the block group is not cached we do a
wait_block_group_cache_progress, which waits for the number of bytes we need,
except the block group already has _plenty_ of free space, its just severely
fragmented, so we loop and try again, ad infinitum.  This patch keeps us from
waiting on the block group to finish caching if we failed to find a free space
cluster before.  It also makes sure that we don't even try to find a free space
cluster if we are on our last loop in the allocator, since we will have tried
everything at this point at it is futile.

Signed-off-by: Josef Bacik <jbacik@redhat.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
fs/btrfs/extent-tree.c