From: "Naohiro Aota" <Naohiro.Aota@wdc.com>
To: "Dongjiang Zhu" <zhudongjiang@fygo.io>, <linux-btrfs@vger.kernel.org>
Cc: <johannes.thumshirn@wdc.com>, <naohiro.aota@wdc.com>
Subject: Re: [PATCH v2 1/4] btrfs: zoned: track only sequential zones as active
Date: Fri, 28 Aug 2026 13:42:27 +0900 [thread overview]
Message-ID: <DL0AVDP5O9C2.1VT2TYQXCL4B4@wdc.com> (raw)
In-Reply-To: <c51aaf7f4621dedc36c275bfa9ba1ec884de09c4.1787717573.git.zhudongjiang@fygo.io>
On Wed Aug 26, 2026 at 1:27 PM JST, Dongjiang Zhu wrote:
> The runtime activation and finish paths apply active-zone accounting to
> both conventional and sequential stripes.
>
> At mount, however, active_zones_left is rebuilt from device zone
> conditions. Conventional zones report NOT_WP and are therefore not
> included. Meanwhile, all-conventional block groups are marked active
> and added to zone_active_bgs, so mount recovery still decreases
> reserved_active_zones for their metadata and system stripes.
>
> The two counters can therefore diverge across a remount.
>
> Each unmatched reservation decrement lets data consume one more
> sequential active-zone slot. Once the reservation becomes negative,
> data can exhaust all such slots.
Yes, apparently, this was not a problem previously, Because,
max_active_zones > 0 mostly means there is no conventional zones. But,
we changed the btrfs_get_max_active_zones() behavior to also use
bdev_max_open_zones() to set the max_active_zones. This is a regressio
introduced by that change, which deserves Fixes tag.
> A later transition from a conventional metadata or system target to a
> sequential one can then fail, because finishing the conventional target
> does not release a sequential active-zone slot.
>
> If this happens during synchronous transaction writeback,
> btrfs_check_meta_write_pointer() returns -EAGAIN. The transaction is
> then aborted and the filesystem is forced read-only.
>
> The reservation mismatch was reproduced by creating small files with
> large xattrs in batches, syncing them and remounting an HC620 filesystem
> using SINGLE profiles:
>
> active_zones_left: 126
> reserved_active_zones: 3 -> -8
>
> The active list contained one partially used conventional system block
> group, nine full conventional metadata block groups and one partially
> used conventional metadata block group.
>
> To keep both counters based on the same physical resource, use
> sequential stripes as the unit of active-zone tracking. Accordingly, do
> not mark all-conventional block groups active, and update the active-zone
> bitmap and non-data reservation only for sequential stripes during
> activation, finish and mount recovery.
>
> Assisted-by: LLM
> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
> Signed-off-by: Dongjiang Zhu <zhudongjiang@fygo.io>
> ---
> fs/btrfs/block-group.h | 6 ++++-
> fs/btrfs/zoned.c | 59 ++++++++++++++++++++++++++++++------------
> 2 files changed, 47 insertions(+), 18 deletions(-)
>
> diff --git a/fs/btrfs/block-group.h b/fs/btrfs/block-group.h
> index 69d56864d4ba..37ab8b7eee9c 100644
> --- a/fs/btrfs/block-group.h
> +++ b/fs/btrfs/block-group.h
> @@ -80,13 +80,17 @@ enum btrfs_block_group_flags {
> BLOCK_GROUP_FLAG_TO_COPY,
> BLOCK_GROUP_FLAG_RELOCATING_REPAIR,
> BLOCK_GROUP_FLAG_CHUNK_ITEM_INSERTED,
> + /*
> + * Only block groups containing sequential zones can have this bit set;
> + * conventional-only block groups never do.
> + */
> BLOCK_GROUP_FLAG_ZONE_IS_ACTIVE,
> BLOCK_GROUP_FLAG_ZONED_DATA_RELOC,
> /* Does the block group need to be added to the free space tree? */
> BLOCK_GROUP_FLAG_NEEDS_FREE_SPACE,
> /* Set after we add a new block group to the free space tree. */
> BLOCK_GROUP_FLAG_FREE_SPACE_ADDED,
> - /* Indicate that the block group is placed on a sequential zone */
> + /* Indicate that the block group contains at least one sequential zone. */
> BLOCK_GROUP_FLAG_SEQUENTIAL_ZONE,
> /*
> * Indicate that block group is in the list of new block groups of a
> diff --git a/fs/btrfs/zoned.c b/fs/btrfs/zoned.c
> index 9d448cdd60c4..0d964ada3ad4 100644
> --- a/fs/btrfs/zoned.c
> +++ b/fs/btrfs/zoned.c
> @@ -1969,7 +1969,6 @@ int btrfs_load_block_group_zone_info(struct btrfs_block_group *cache, bool new)
> } else if (map->num_stripes == num_conventional) {
> cache->alloc_offset = last_alloc;
> cache->zone_capacity = cache->length;
> - set_bit(BLOCK_GROUP_FLAG_ZONE_IS_ACTIVE, &cache->runtime_flags);
> goto out;
> }
> }
> @@ -2005,6 +2004,8 @@ int btrfs_load_block_group_zone_info(struct btrfs_block_group *cache, bool new)
> if (!ret) {
> cache->meta_write_pointer = cache->alloc_offset + cache->start;
> if (test_bit(BLOCK_GROUP_FLAG_ZONE_IS_ACTIVE, &cache->runtime_flags)) {
> + ASSERT(test_bit(BLOCK_GROUP_FLAG_SEQUENTIAL_ZONE,
> + &cache->runtime_flags));
> btrfs_get_block_group(cache);
> spin_lock(&fs_info->zone_active_bgs_lock);
> list_add_tail(&cache->active_bg_list,
> @@ -2198,6 +2199,9 @@ static bool check_bg_is_active(struct btrfs_eb_write_context *ctx,
> if (test_bit(BLOCK_GROUP_FLAG_ZONE_IS_ACTIVE, &block_group->runtime_flags))
> return true;
>
> + if (!test_bit(BLOCK_GROUP_FLAG_SEQUENTIAL_ZONE, &block_group->runtime_flags))
> + return true;
> +
> if (fs_info->treelog_bg == block_group->start) {
> if (!btrfs_zone_activate(block_group)) {
> int ret_fin;
> @@ -2394,6 +2398,18 @@ int btrfs_sync_zone_write_pointer(struct btrfs_device *tgt_dev, u64 logical,
> return btrfs_zoned_issue_zeroout(tgt_dev, physical_pos, length);
> }
>
> +static inline bool btrfs_needs_active_zone_tracking(struct btrfs_device *dev,
> + u64 physical)
> +{
> + if (!btrfs_dev_is_sequential(dev, physical))
> + return false;
> +
> + if (dev->zone_info->max_active_zones == 0)
> + return false;
Apparently, since we use bdev_max_open_zones() to populate
zone_info->max_active_zones, we won't have max_active_zones == 0 now?
> +
> + return true;
> +}
> +
> /*
> * Activate block group and underlying device zones
> *
> @@ -2417,6 +2433,9 @@ bool btrfs_zone_activate(struct btrfs_block_group *block_group)
> if (unlikely(btrfs_is_testing(fs_info)))
> return true;
>
> + if (!test_bit(BLOCK_GROUP_FLAG_SEQUENTIAL_ZONE, &block_group->runtime_flags))
> + return true;
> +
> map = block_group->physical_map;
>
> spin_lock(&fs_info->zone_active_bgs_lock);
> @@ -2448,7 +2467,7 @@ bool btrfs_zone_activate(struct btrfs_block_group *block_group)
> if (!device->bdev)
> continue;
>
> - if (zinfo->max_active_zones == 0)
> + if (!btrfs_needs_active_zone_tracking(device, physical))
> continue;
>
> if (is_data)
> @@ -2514,26 +2533,22 @@ static int call_zone_finish(struct btrfs_block_group *block_group,
> struct btrfs_device *device = stripe->dev;
> const u64 physical = stripe->physical;
> struct btrfs_zoned_device_info *zinfo = device->zone_info;
> + unsigned int nofs_flags;
> int ret;
>
> if (!device->bdev)
> return 0;
>
> - if (zinfo->max_active_zones == 0)
> + if (!btrfs_needs_active_zone_tracking(device, physical))
> return 0;
>
> - if (btrfs_dev_is_sequential(device, physical)) {
> - unsigned int nofs_flags;
> -
> - nofs_flags = memalloc_nofs_save();
> - ret = blkdev_zone_mgmt(device->bdev, REQ_OP_ZONE_FINISH,
> - physical >> SECTOR_SHIFT,
> - zinfo->zone_size >> SECTOR_SHIFT);
> - memalloc_nofs_restore(nofs_flags);
> -
> - if (ret)
> - return ret;
> - }
> + nofs_flags = memalloc_nofs_save();
> + ret = blkdev_zone_mgmt(device->bdev, REQ_OP_ZONE_FINISH,
> + physical >> SECTOR_SHIFT,
> + zinfo->zone_size >> SECTOR_SHIFT);
> + memalloc_nofs_restore(nofs_flags);
> + if (ret)
> + return ret;
>
> if (!(block_group->flags & BTRFS_BLOCK_GROUP_DATA))
> zinfo->reserved_active_zones++;
> @@ -3087,8 +3102,18 @@ void btrfs_check_active_zone_reservation(struct btrfs_fs_info *fs_info)
> (BTRFS_BLOCK_GROUP_METADATA | BTRFS_BLOCK_GROUP_SYSTEM)))
> continue;
>
> - for (int i = 0; i < map->num_stripes; i++)
> - map->stripes[i].dev->zone_info->reserved_active_zones--;
> + for (int i = 0; i < map->num_stripes; i++) {
> + struct btrfs_device *device = map->stripes[i].dev;
> + u64 physical = map->stripes[i].physical;
> +
> + if (!device->bdev)
> + continue;
> +
> + if (!btrfs_needs_active_zone_tracking(device, physical))
> + continue;
> +
> + device->zone_info->reserved_active_zones--;
> + }
> }
> spin_unlock(&fs_info->zone_active_bgs_lock);
> }
Also, as you dropped a BG on conventional zones from the
zone_active_bgs, prepare_allocation_zoned() will never return the
conventional BG to allocate with.
next prev parent reply other threads:[~2026-08-28 4:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 4:27 [PATCH v2 0/4] btrfs: zoned: fix active-zone accounting and transitions Dongjiang Zhu
2026-08-26 4:27 ` [PATCH v2 1/4] btrfs: zoned: track only sequential zones as active Dongjiang Zhu
2026-08-26 9:00 ` Johannes Thumshirn
2026-08-27 2:06 ` Dongjiang Zhu
2026-08-28 4:42 ` Naohiro Aota [this message]
2026-08-28 12:03 ` Dongjiang Zhu
2026-08-26 4:27 ` [PATCH v2 2/4] btrfs: zoned: recover active non-data block group roles on mount Dongjiang Zhu
2026-08-26 4:27 ` [PATCH v2 3/4] btrfs: zoned: remove obsolete non-data block group activation helper Dongjiang Zhu
2026-08-26 4:27 ` [PATCH v2 4/4] btrfs: zoned: serialize zone finishing per block group Dongjiang Zhu
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=DL0AVDP5O9C2.1VT2TYQXCL4B4@wdc.com \
--to=naohiro.aota@wdc.com \
--cc=johannes.thumshirn@wdc.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=zhudongjiang@fygo.io \
/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