Btrfs devel - May 2013 - [PATCH] Btrfs: increase the max global reserve size to 1gig

Apparently 512mb was too small, with a fs_mark command we could get so much
delayed work built up that we''d never trip the "lets commit the
transaction"
logic until we''d gotten too much delayed refs built up.  Increasing
this to 1
gig makes us much safer and we no longer abort with Dave''s fs_mark
tester.
Thanks,

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

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 7049bbc..f10ac46 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4516,7 +4516,7 @@ static void update_global_block_rsv(struct btrfs_fs_info
*fs_info)
 	spin_lock(&sinfo->lock);
 	spin_lock(&block_rsv->lock);
 
-	block_rsv->size = min_t(u64, num_bytes, 512 * 1024 * 1024);
+	block_rsv->size = min_t(u64, num_bytes, 1024 * 1024 * 1024);
 
 	num_bytes = sinfo->bytes_used + sinfo->bytes_pinned +
 		    sinfo->bytes_reserved + sinfo->bytes_readonly +
-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Fri, May 03, 2013 at 08:56:54AM -0400, Josef Bacik
wrote:
> Apparently 512mb was too small, with a fs_mark command we could get so much
> delayed work built up that we''d never trip the "lets commit
the transaction"
> logic until we''d gotten too much delayed refs built up. 
Increasing this to 1
> gig makes us much safer and we no longer abort with Dave''s fs_mark
tester.
> Thanks,
I remember that last time I made a similar commit, but users complains that
they cannot boot their system on root btrfs partition due to lacking space and
Chris eventually got to revert that one...

thanks,
liubo
> 
> Signed-off-by: Josef Bacik <jbacik@fusionio.com>
> ---
>  fs/btrfs/extent-tree.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index 7049bbc..f10ac46 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -4516,7 +4516,7 @@ static void update_global_block_rsv(struct
btrfs_fs_info *fs_info)
>  	spin_lock(&sinfo->lock);
>  	spin_lock(&block_rsv->lock);
>  
> -	block_rsv->size = min_t(u64, num_bytes, 512 * 1024 * 1024);
> +	block_rsv->size = min_t(u64, num_bytes, 1024 * 1024 * 1024);
>  
>  	num_bytes = sinfo->bytes_used + sinfo->bytes_pinned +
>  		    sinfo->bytes_reserved + sinfo->bytes_readonly +
> -- 
> 1.7.7.6
> 
> --
> To unsubscribe from this list: send the line "unsubscribe
linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Fri, May 03, 2013 at 11:28:35PM +0800, Liu Bo wrote:
> On Fri, May 03, 2013 at 08:56:54AM -0400, Josef Bacik wrote:
> > Apparently 512mb was too small, with a fs_mark command we could get so
much
> > delayed work built up that we''d never trip the "lets
commit the transaction"
> > logic until we''d gotten too much delayed refs built up. 
Increasing this to 1
> > gig makes us much safer and we no longer abort with Dave''s
fs_mark tester.
> > Thanks,
> 
> I remember that last time I made a similar commit, but users complains that
> they cannot boot their system on root btrfs partition due to lacking space
and
> Chris eventually got to revert that one...
That was long time ago (3.5) and enospc has been updated since, so this
needs re-evaluation if it still leads to early enospc.

This patch is not in next queue, i wonder if your concern is the reason
of that.

david
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Fri, May 03, 2013 at 08:56:54AM -0400, Josef Bacik
wrote:
> Apparently 512mb was too small, with a fs_mark command we could get so much
> delayed work built up that we''d never trip the "lets commit
the transaction"
> logic until we''d gotten too much delayed refs built up. 
Increasing this to 1
> gig makes us much safer and we no longer abort with Dave''s fs_mark
tester.
With this patch on top of today''s next I still hit the abort and will
file a bug.

david
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html