[PATCH] Btrfs: increase the size of the free space cache

[PATCH] Btrfs: increase the size of the free space cache

[Josef Bacik]

Arne was complaining about the space cache having mismatching generation
numbers when debugging a deadlock.  This is because we can run out of space
in our preallocated range for our space cache if you have a pretty
fragmented amount of space in your pinned space.  So just increase the
amount of space we preallocate for space cache so we can be sure to have
enough space.  This will only really affect data ranges since their the only
chunks that end up larger than 256MB.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
---
 fs/btrfs/extent-tree.c |   15 +++++++--------
 1 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 45c69c4..55d33b8 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3007,17 +3007,16 @@ again:
 	}
 	spin_unlock(&block_group->lock);
 
-	num_pages = (int)div64_u64(block_group->key.offset, 1024 * 1024 * 1024);
+	/*
+	 * Try to preallocate enough space based on how big the block group is.
+	 * Keep in mind this has to include any pinned space which could end up
+	 * taking up quite a bit since it's not folded into the other space
+	 * cache.
+	 */
+	num_pages = (int)div64_u64(block_group->key.offset, 256 * 1024 * 1024);
 	if (!num_pages)
 		num_pages = 1;
 
-	/*
-	 * Just to make absolutely sure we have enough space, we're going to
-	 * preallocate 12 pages worth of space for each block group.  In
-	 * practice we ought to use at most 8, but we need extra space so we can
-	 * add our header and have a terminator between the extents and the
-	 * bitmaps.
-	 */
 	num_pages *= 16;
 	num_pages *= PAGE_CACHE_SIZE;
 
-- 
1.7.7.6

Re: [PATCH] Btrfs: increase the size of the free space cache

[Arne Jansen]

On 08/06/2012 09:46 PM, Josef Bacik wrote:
> Arne was complaining about the space cache having mismatching generation
> numbers when debugging a deadlock.  This is because we can run out of space
> in our preallocated range for our space cache if you have a pretty
> fragmented amount of space in your pinned space.  So just increase the
> amount of space we preallocate for space cache so we can be sure to have
> enough space.  This will only really affect data ranges since their the only
> chunks that end up larger than 256MB.  Thanks,
> 
> Signed-off-by: Josef Bacik <jbacik@fusionio.com>

Arne does not complain anymore.

Tested-by: Arne Jansen <sensille@gmx.net>

> ---
>  fs/btrfs/extent-tree.c |   15 +++++++--------
>  1 files changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index 45c69c4..55d33b8 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -3007,17 +3007,16 @@ again:
>  	}
>  	spin_unlock(&block_group->lock);
>  
> -	num_pages = (int)div64_u64(block_group->key.offset, 1024 * 1024 * 1024);
> +	/*
> +	 * Try to preallocate enough space based on how big the block group is.
> +	 * Keep in mind this has to include any pinned space which could end up
> +	 * taking up quite a bit since it's not folded into the other space
> +	 * cache.
> +	 */
> +	num_pages = (int)div64_u64(block_group->key.offset, 256 * 1024 * 1024);
>  	if (!num_pages)
>  		num_pages = 1;
>  
> -	/*
> -	 * Just to make absolutely sure we have enough space, we're going to
> -	 * preallocate 12 pages worth of space for each block group.  In
> -	 * practice we ought to use at most 8, but we need extra space so we can
> -	 * add our header and have a terminator between the extents and the
> -	 * bitmaps.
> -	 */
>  	num_pages *= 16;
>  	num_pages *= PAGE_CACHE_SIZE;
>  
>