Re: [PATCH v2 1/4] btrfs: zoned: track only sequential zones as active

["Dongjiang Zhu" <zhudongjiang@fygo.io>]

在 2026/8/28 12:42, Naohiro Aota 写道:
> 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.
> 

Agreed.  I will add the Fixes tag in the next revision.

>>
>> [...]
>>
>> +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?
> 

It can still be zero.  btrfs_get_max_active_zones() initially assigns a
non-zero value, but btrfs_get_dev_zone_info() resets it to zero for
backward compatibility when nactive exceeds the derived limit and the
device reports no hardware max_active_zones limit.  The per-device check
is therefore still needed.

>>
>> [...]
>>
> 
> 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.

Thanks for pointing this out.

I intentionally changed zone_active_bgs so that conventional-only block
groups are excluded.  I understood that this would also affect the
candidates used by prepare_allocation_zoned().

As I understand it, this is only an initial allocation hint.  Conventional
block groups are no longer preferred through this path, but can still be
selected by the subsequent block group scan.  Am I missing anything here?

My original plan was to address the allocation policy separately after this
series.  I also compared the baseline and the full series with conventional
and sequential data/metadata workloads and did not observe a measurable
performance regression.

As a separate question, on devices with both conventional and sequential
zones, should allocation generally prefer conventional zones, or balance
them with active sequential zones?  Besides preserving active-zone slots,
are there performance or endurance differences that should guide this
policy?

Thanks for the review,
Dongjiang Zhu