Re: [PATCH 07/13] block: track zone conditions

[Bart Van Assche <bvanassche@acm.org>]

On 10/30/25 11:13 PM, Damien Le Moal wrote:
> Implement tracking of the runtime changes to zone conditions using
> the new cond field in struct blk_zone_wplug. The size of this structure
> remains 112 Bytes as the new field replaces the 4 Bytes padding at the
> end of the structure. For zones that do not have a zone write plug, the
> zones_cond array of a disk is used to track changes to zone conditions,
> e.g. when a zone reset, reset all or finish operation is executed.

Why is it necessary to track the condition of sequential zones that do
not have a zone write plug? Please explain what the use cases are.

The zoned UFS device on my desk has 3420 sequential zones and zero
conventional zones. If the condition of zones that do not have a zone
write plug wouldn't be tracked that would save some memory.
> +static void blk_zone_set_cond(u8 *zones_cond, unsigned int zno,
> +			      enum blk_zone_cond cond)
> +{
> +	if (!zones_cond)
> +		return;
> +
> +	switch (cond) {
> +	case BLK_ZONE_COND_IMP_OPEN:
> +	case BLK_ZONE_COND_EXP_OPEN:
> +	case BLK_ZONE_COND_CLOSED:
> +		zones_cond[zno] = BLK_ZONE_COND_ACTIVE;
> +		return;
> +	case BLK_ZONE_COND_NOT_WP:
> +	case BLK_ZONE_COND_EMPTY:
> +	case BLK_ZONE_COND_FULL:
> +	case BLK_ZONE_COND_OFFLINE:
> +	case BLK_ZONE_COND_READONLY:
> +	default:
> +		zones_cond[zno] = cond;
> +		return;
> +	}
> +}
> +
> +static void disk_zone_set_cond(struct gendisk *disk, sector_t sector,
> +			       enum blk_zone_cond cond)
> +{
> +	u8 *zones_cond;
> +
> +	rcu_read_lock();
> +	zones_cond = rcu_dereference(disk->zones_cond);
> +	if (zones_cond) {
> +		unsigned int zno = disk_zone_no(disk, sector);
> +
> +		/*
> +		 * The condition of a conventional, readonly and offline zones
> +		 * never changes, so do nothing if the target zone is in one of
> +		 * these conditions.
> +		 */
> +		switch (zones_cond[zno]) {
> +		case BLK_ZONE_COND_NOT_WP:
> +		case BLK_ZONE_COND_READONLY:
> +		case BLK_ZONE_COND_OFFLINE:
> +			break;
> +		default:
> +			blk_zone_set_cond(zones_cond, zno, cond);
> +			break;
> +		}
> +	}
> +	rcu_read_unlock();
> +}

Why does blk_zone_set_cond() accept a zone number as second argument and
why does disk_zone_set_cond() accept a sector number as second argument?
The callers of disk_zone_set_cond() can be optimized if its second
argument would be changed from a sector number into a zone number.

Thanks,

Bart.