All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: Josef Bacik <josef@toxicpanda.com>,
	kernel-team@fb.com, linux-btrfs@vger.kernel.org
Cc: Nikolay Borisov <nborisov@suse.com>
Subject: Re: [PATCH 4/5] btrfs: do not account global reserve in can_overcommit
Date: Fri, 24 Jan 2020 00:14:34 +0800	[thread overview]
Message-ID: <8b7d11d3-3f54-d090-a1c6-cb1e67b2b4f1@oracle.com> (raw)
In-Reply-To: <20190822191904.13939-5-josef@toxicpanda.com>



This patch is causing regression in the test case generic/027
and generic/275 with MKFS_OPTIONS="-n64K" on x86_64.

Both of these tests, test FS behavior at ENOSPC.

In generic/027, it fails to delete a file with ENOSPC

      +rm: cannot remove '/mnt/scratch/testdir/6/file_1598': No space 
left on device

In generic/275, it failed to create at least 128k size file after
deleting 256k sized file. Failure may be fair taking into the cow part,
but any idea why it could be successful before this patch?

     +du: cannot access '/mnt/scratch/tmp1': No such file or directory
     +stat: cannot stat '/mnt/scratch/tmp1': No such file or directory

These fail on misc-next as well.

Thanks, Anand


On 8/23/19 3:19 AM, Josef Bacik wrote:
> We ran into a problem in production where a box with plenty of space was
> getting wedged doing ENOSPC flushing.  These boxes only had 20% of the
> disk allocated, but their metadata space + global reserve was right at
> the size of their metadata chunk.
> 
> In this case can_overcommit should be allowing allocations without
> problem, but there's logic in can_overcommit that doesn't allow us to
> overcommit if there's not enough real space to satisfy the global
> reserve.
> 
> This is for historical reasons.  Before there were only certain places
> we could allocate chunks.  We could go to commit the transaction and not
> have enough space for our pending delayed refs and such and be unable to
> allocate a new chunk.  This would result in a abort because of ENOSPC.
> This code was added to solve this problem.
> 
> However since then we've gained the ability to always be able to
> allocate a chunk.  So we can easily overcommit in these cases without
> risking a transaction abort because of ENOSPC.
> 
> Also prior to now the global reserve really would be used because that's
> the space we relied on for delayed refs.  With delayed refs being
> tracked separately we no longer have to worry about running out of
> delayed refs space while committing.  We are much less likely to
> exhaust our global reserve space during transaction commit.
> 
> Fix the can_overcommit code to simply see if our current usage + what we
> want is less than our current free space plus whatever slack space we
> have in the disk is.  This solves the problem we were seeing in
> production and keeps us from flushing as aggressively as we approach our
> actual metadata size usage.
> 
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> Reviewed-by: Nikolay Borisov <nborisov@suse.com>
> ---
>   fs/btrfs/space-info.c | 19 +------------------
>   1 file changed, 1 insertion(+), 18 deletions(-)
> 
> diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c
> index a43f6287074b..3053b3e91b34 100644
> --- a/fs/btrfs/space-info.c
> +++ b/fs/btrfs/space-info.c
> @@ -165,9 +165,7 @@ static int can_overcommit(struct btrfs_fs_info *fs_info,
>   			  enum btrfs_reserve_flush_enum flush,
>   			  bool system_chunk)
>   {
> -	struct btrfs_block_rsv *global_rsv = &fs_info->global_block_rsv;
>   	u64 profile;
> -	u64 space_size;
>   	u64 avail;
>   	u64 used;
>   	int factor;
> @@ -181,22 +179,7 @@ static int can_overcommit(struct btrfs_fs_info *fs_info,
>   	else
>   		profile = btrfs_metadata_alloc_profile(fs_info);
>   
> -	used = btrfs_space_info_used(space_info, false);
> -
> -	/*
> -	 * We only want to allow over committing if we have lots of actual space
> -	 * free, but if we don't have enough space to handle the global reserve
> -	 * space then we could end up having a real enospc problem when trying
> -	 * to allocate a chunk or some other such important allocation.
> -	 */
> -	spin_lock(&global_rsv->lock);
> -	space_size = calc_global_rsv_need_space(global_rsv);
> -	spin_unlock(&global_rsv->lock);
> -	if (used + space_size >= space_info->total_bytes)
> -		return 0;
> -
> -	used += space_info->bytes_may_use;
> -
> +	used = btrfs_space_info_used(space_info, true);
>   	avail = atomic64_read(&fs_info->free_chunk_space);
>   
>   	/*
> 


  reply	other threads:[~2020-01-23 16:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-22 19:18 [PATCH 0/5][v2] Fix global reserve size and can overcommit Josef Bacik
2019-08-22 19:19 ` [PATCH 1/5] btrfs: change the minimum global reserve size Josef Bacik
2019-08-22 19:19 ` [PATCH 2/5] btrfs: always reserve our entire size for the global reserve Josef Bacik
2019-08-22 19:19 ` [PATCH 3/5] btrfs: use btrfs_try_granting_tickets in update_global_rsv Josef Bacik
2019-08-22 19:19 ` [PATCH 4/5] btrfs: do not account global reserve in can_overcommit Josef Bacik
2020-01-23 16:14   ` Anand Jain [this message]
2020-01-24  0:48     ` Josef Bacik
2019-08-22 19:19 ` [PATCH 5/5] btrfs: add enospc debug messages for ticket failure Josef Bacik
2019-08-23 13:17 ` [PATCH 0/5][v2] Fix global reserve size and can overcommit David Sterba
2019-08-28 18:03   ` David Sterba
  -- strict thread matches above, loose matches on Subject: below --
2019-08-16 15:20 [PATCH 0/5] " Josef Bacik
2019-08-16 15:20 ` [PATCH 4/5] btrfs: do not account global reserve in can_overcommit Josef Bacik
2019-08-21  6:51   ` Nikolay Borisov
2019-08-21 15:30   ` Vladimir Panteleev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8b7d11d3-3f54-d090-a1c6-cb1e67b2b4f1@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=josef@toxicpanda.com \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.