Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Naohiro Aota <naohiro.aota@wdc.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: zoned: fix initial free space detection
Date: Wed, 12 Jun 2024 21:51:29 +0200	[thread overview]
Message-ID: <20240612195129.GN18508@twin.jikos.cz> (raw)
In-Reply-To: <ec2aafb75c235d9c37aef52068992dca0d060d5f.1718096605.git.naohiro.aota@wdc.com>

On Tue, Jun 11, 2024 at 06:05:52PM +0900, Naohiro Aota wrote:
> When creating a new block group, it calls btrfs_fadd_new_free_space() to
> add the entire block group range into the free space
> accounting. __btrfs_add_free_space_zoned() checks if size ==
> block_group->length to detect the initial free space adding, and proceed
> that case properly.
> 
> However, if the zone_capacity == zone_size and the over-write speed is fast
> enough, the entire zone can be over-written within one transaction. That
> confuses __btrfs_add_free_space_zoned() to handle it as an initial free
> space accounting. As a result, that block group becomes a strange state: 0
> used bytes, 0 zone_unusable bytes, but alloc_offset == zone_capacity (no
> allocation anymore).
> 
> The initial free space accounting can properly be checked by checking
> alloc_offset too.
> 
> Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
> Fixes: 98173255bddd ("btrfs: zoned: calculate free space from zone capacity")
> CC: stable@vger.kernel.org # 6.1+
> ---
>  fs/btrfs/free-space-cache.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
> index fcfc1b62e762..72e60764d1ea 100644
> --- a/fs/btrfs/free-space-cache.c
> +++ b/fs/btrfs/free-space-cache.c
> @@ -2697,7 +2697,7 @@ static int __btrfs_add_free_space_zoned(struct btrfs_block_group *block_group,
>  	u64 offset = bytenr - block_group->start;
>  	u64 to_free, to_unusable;
>  	int bg_reclaim_threshold = 0;
> -	bool initial = (size == block_group->length);
> +	bool initial = (size == block_group->length) && block_group->alloc_offset == 0;

I'm not recommending to use compound conditions in the initializer block
as it can hide some important detail, but in this case it's both related
to the block group and still related to the variable name. Please put
the pair of ( ) to the whole expression.

Reviewed-by: David Sterba <dsterba@suse.com>

  parent reply	other threads:[~2024-06-12 19:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-11  9:05 [PATCH] btrfs: zoned: fix initial free space detection Naohiro Aota
2024-06-11 10:45 ` Johannes Thumshirn
2024-06-13  0:18   ` Naohiro Aota
2024-06-12 19:51 ` David Sterba [this message]
2024-06-13  0:18   ` Naohiro Aota
2024-06-13 15:09     ` David Sterba

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=20240612195129.GN18508@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=naohiro.aota@wdc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox