All of lore.kernel.org
 help / color / mirror / Atom feed
From: Naohiro Aota <Naohiro.Aota@wdc.com>
To: Naohiro Aota <Naohiro.Aota@wdc.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] btrfs: zoned: fixup last alloc pointer after extent removal for RAID1
Date: Wed, 17 Dec 2025 11:07:03 +0000	[thread overview]
Message-ID: <DF0FZH14M9OU.2HERAS6FMC51C@wdc.com> (raw)
In-Reply-To: <20251217103451.646206-1-naohiro.aota@wdc.com>

On Wed Dec 17, 2025 at 7:34 PM JST, Naohiro Aota wrote:
> When a block group is composed of a sequential write zone and a conventional
> zone, we recover the (pseudo) write pointer of the conventional zone using the
> end of the last allocated position.
>
> However, if the last extent in a block group is removed, the last extent
> position will be smaller than the other real write pointer position. Then, that
> will cause an error due to mismatch of the write pointers.
>
> We can fixup this case by moving the alloc_offset to the corresponding write
> pointer position.
>
> Fixes: 568220fa9657 ("btrfs: zoned: support RAID0/1/10 on top of raid stripe tree")
> CC: stable@vger.kernel.org # 6.12+
> Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
> ---
>  fs/btrfs/zoned.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>
> diff --git a/fs/btrfs/zoned.c b/fs/btrfs/zoned.c
> index 359a98e6de85..17dde95eb3e7 100644
> --- a/fs/btrfs/zoned.c
> +++ b/fs/btrfs/zoned.c
> @@ -1490,6 +1490,23 @@ static int btrfs_load_block_group_raid1(struct btrfs_block_group *bg,
>  	/* In case a device is missing we have a cap of 0, so don't use it. */
>  	bg->zone_capacity = min_not_zero(zone_info[0].capacity, zone_info[1].capacity);
>  
> +	if (last_alloc) {

Oops, we don't need this "if" because we need to run this even if we
have no extents (alloc_offset == 0) and the write pointer > 0.

> +		/*
> +		 * When the last extent is removed, last_alloc can be smaller
> +		 * than the other write pointer. In that case, last_alloc should
> +		 * be moved to the corresponding write pointer position.
> +		 */
> +		for (i = 0; i < map->num_stripes; i++) {
> +			if (zone_info[i].alloc_offset == WP_MISSING_DEV ||
> +			    zone_info[i].alloc_offset == WP_CONVENTIONAL)
> +				continue;
> +			if (last_alloc <= zone_info[i].alloc_offset) {
> +				last_alloc = zone_info[i].alloc_offset;
> +				break;
> +			}
> +		}
> +	}
> +
>  	for (i = 0; i < map->num_stripes; i++) {
>  		if (zone_info[i].alloc_offset == WP_MISSING_DEV)
>  			continue;

      reply	other threads:[~2025-12-17 11:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-17 10:34 [PATCH] btrfs: zoned: fixup last alloc pointer after extent removal for RAID1 Naohiro Aota
2025-12-17 11:07 ` Naohiro Aota [this message]

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=DF0FZH14M9OU.2HERAS6FMC51C@wdc.com \
    --to=naohiro.aota@wdc.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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.