Re: [PATCH 2/4] xfs: handle too many open zones when mounting

[Damien Le Moal <dlemoal@kernel.org>]

On 3/30/26 14:40, Christoph Hellwig wrote:
> When running on conventional zones or devices, the zoned allocator does
> not have a real write pointer, but instead fakes it up at mount time
> based on the last block recorded in the rmap.  This can create spurious
> "open" zones when the last written blocks in a conventional zone are
> invalidated.  Add a loop to the mount code to find the conventional zones
> with the most used space and "finish" them.
> 
> While we're at it, also error out if there are too many open sequential
> zones, which can only happen when the user overrode the max open zones
> limit (or with really buggy hardware reducing the limit, but not much
> we can do about that).
> 
> Fixes: 4e4d52075577 ("xfs: add the zoned space allocator")
> Signed-off-by: Christoph Hellwig <hch@lst.de>

> +/*
> + * Find the fullest conventional zones and remove them from the open zone pool
> + * until we are at the open zone limit.
> + *
> + * We can end up with spurious "open" zones when the last blocks in a fully
> + * written zone were invalidate as there is no write pointer for conventional
> + * zone.

s/zone./zones.

> + *
> + * If we are still over the limit when there is no conventional open zone left,
> + * the user manually overrode the max open zones limit and we should fail.
> + */

"manually overrode the max open zones limit" sound a little odd and not clear,
since the maximum open zone limit is a read-only hardware limit. What can lead
to this is that someone wrote directly to the drive to some empty zones with the
FS unmounted, no ? (same comment for the commit message)

Other that the above 2 nits, this looks OK to me.


-- 
Damien Le Moal
Western Digital Research