Linux block layer
 help / color / mirror / Atom feed
From: Damien Le Moal <dlemoal@kernel.org>
To: raoxu <raoxu@uniontech.com>
Cc: axboe@kernel.dk, hch@lst.de, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] zloop: round capacity up to a zone-size multiple
Date: Mon, 3 Aug 2026 22:02:05 +0900	[thread overview]
Message-ID: <0be2d538-8e18-45ad-9181-f7e3fb7e02ed@kernel.org> (raw)
In-Reply-To: <906CDA1B6AAAD5B8+20260803095810.3453016-1-raoxu@uniontech.com>

On 8/3/26 18:58, raoxu wrote:
> From: Xu Rao <raoxu@uniontech.com>
> 
> zloop_ctl_add() derives the number of zones by shifting the requested
> capacity by ilog2(zone_size). Since zone_size is validated as a power of
> two, this is equivalent to integer division and discards any remainder.
> However, Documentation/admin-guide/blockdev/zoned_loop.rst specifies that
> capacity_mb is always rounded up to the nearest higher multiple of the
> zone size.
> 
> Only configurations whose requested capacity is not aligned to the zone
> size are affected. Aligned configurations, including the defaults of
> 16384 MiB capacity and 256 MiB zones, keep the same geometry. An affected
> device is also internally consistent and remains usable, but it is
> smaller than requested. For example, capacity_mb=130 with
> zone_size_mb=64 currently creates two zones and exposes 128 MiB instead
> of the documented three zones and 192 MiB. Since this does not cause an
> error or an I/O failure, and normal test configurations generally use an
> integral number of zones, the discrepancy can remain unnoticed.
> 
> Calculate the number of zones with DIV_ROUND_UP_SECTOR_T() so a partial
> final zone request is represented by one additional full zone. This
> matches the documented control interface while preserving the existing
> sector_t handling on both 32-bit and 64-bit architectures.
> 
> Fixes: eb0570c7df23 ("block: new zoned loop block device driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Xu Rao <raoxu@uniontech.com>
> ---
>  drivers/block/zloop.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/block/zloop.c b/drivers/block/zloop.c
> index b69d798f203c..e29d82ff52ae 100644
> --- a/drivers/block/zloop.c
> +++ b/drivers/block/zloop.c
> @@ -1187,7 +1187,7 @@ static int zloop_ctl_add(struct zloop_options *opts)
> 
>  	__module_get(THIS_MODULE);
> 
> -	nr_zones = opts->capacity >> ilog2(opts->zone_size);
> +	nr_zones = DIV_ROUND_UP_SECTOR_T(opts->capacity, opts->zone_size);

Your explanation and this change are consistent, but this is going to break many
things because we do not maintain the size of zone per zone and instead always
use zlo->zone_size, assuming that all zones have the same size.
Your change would result in bad things. For instance, zloop_finish_zone()
truncates a zone file to zlo->zone_size, which would be too big for a last runt
zone smaller than other zones.

So nack for this patch. Instead, I think we should fix the documentation to make
more explicit that we do not support a smaller last zone.

>  	if (opts->nr_conv_zones >= nr_zones) {
>  		pr_err("Invalid number of conventional zones %u\n",
>  		       opts->nr_conv_zones);
> --
> 2.50.1
> 


-- 
Damien Le Moal
Western Digital Research

  reply	other threads:[~2026-08-03 13:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-03  9:58 [PATCH] zloop: round capacity up to a zone-size multiple raoxu
2026-08-03 13:02 ` Damien Le Moal [this message]
2026-08-04  3:41   ` [PATCH v2] Documentation: block: zloop: clarify capacity alignment raoxu
2026-08-04  4:29     ` Damien Le Moal
2026-08-04  5:29       ` [PATCH v3] " raoxu
2026-08-04 13:05         ` Christoph Hellwig
2026-08-04 13:21         ` Jens Axboe

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=0be2d538-8e18-45ad-9181-f7e3fb7e02ed@kernel.org \
    --to=dlemoal@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=raoxu@uniontech.com \
    --cc=stable@vger.kernel.org \
    /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