Re: [BUG] active zones exceeded error with max_open_zones

[Sean Anderson <seanga2@gmail.com>]

On 4/24/25 01:40, Damien Le Moal wrote:
> On 4/24/25 14:27, Sean Anderson wrote:
>> On 4/23/25 23:10, Damien Le Moal wrote:
>>> On 4/24/25 02:11, Sean Anderson wrote:
>>>> Hi,
>>>>
>>>> I'm getting an "active zones exceeded" error when running fio with
>>>> --rw=randwrite mode:
>>>>
>>>> # fio --bs=4k --rw=randwrite --norandommap --fsync=1 --number_ios=16384 --name=flushes --direct=1 --zonemode=zbd --max_open_zones=1978 --filename=/dev/my_zone_dev
>>>
>>> --max_open_zones=1978 is an extremely large value that likely exceeds the drive
>>> capabilities, which is what fio is telling you.
>>> What are your drive maximum open and active zones limits ?
>>>
>>> cat /sys/block/my_zone_dev/queue/max_open_zones
>>> cat /sys/block/my_zone_dev/queue/max_active_zones
>>
>> This is correct for the drive.
> 
> I am sure it is. My point is that you cannot use --max_open_zone fio option with
> a value larger than what these sysfs attribute values are.

as I said

# cat /sys/block/my_zone_dev/queue/max_open_zones
1978
# cat /sys/block/my_zone_dev/queue/max_active_zones
1978

>>> fio will use the min_not_zero of these 2 values as the maximum number of zones
>>> that can be written simultaneously. Especially if your drive has an active zone
>>> limit, you *cannot* write to more zones than that limit at the same time.
>>> fio will default to max_open_zones=min_not_zero(drive max open, drive max
>>> active) and for a random write workload, it will:
>>> - pick zones randomly up to max_open_zones
>>> - direct write IOs to a randomly chosen zone in the current set of open zones
>>> and when an open zone becomes full, randomly pick another zone to replace it.
>>
>> Well the issue is that it appears to just pick random zones, not random open zones.
> 
> The drive may be completely empty, all zones empty, so no open zones to chose
> from. So fio picks a random zone and adds it to the set of open zones it tracks.
> It will repeat that until the set of open zones reaches the limit, at which
> point, fio has no choice but to keep writting these open zones until they are full.
> 
> If the drive already has open zone in the fio workload range, these zones will
> be added to the set of open zones on fio start.

But it's not doing this.

>>> For your workload, if you want to measure the maximum "random" write performance
>>> of your disk, simply do NOT specify --max_open_zones=. fio will pick the best
>>> possible number for you.
>>
>> Same issue.
> 
> Are you specifying an offset+size range ? If yes, how many zones are open in
> that range and outside of it ?

The full command line and output is in my original email. I ran `blkzone reset`
before this. If I don't do a reset first it fails almost immediately.

> What drive is it ? Looking at the blkzone report you sent, the zones look
> ridiculously small (32 sectors...)... Is this a null_blk device ?

Something I'm working on. I'm not done testing yet (which is why I was messing around
with fio). You can probably guess what it is based on the geometry.

I'm actually thinking of creating a device mapper driver (layer?) to combine the zones
because a lot of other layers expect larger zones. E.g. btrfs expects 4M zones. Not
sure whether it should go under linear or not.

But tbh this is a bit strange to me. Ideally filesystems should take advantage of smaller
zones because they more closely approximate conventional zones. And if they need to store
larger structures they should just store them in multiple zones.

> If that is the case, try creating the drive with larger zones. You may be
> hitting a bug with such tiny zones. Since such drive do not exist in the field,
> we never really tested such extreme configuration.

The hardware I am targeting naturally has small zones, so I am interested in finding/fixing
these sorts of bugs.

--Sean