[PATCH blktests] zbd/005: Limit block size to zone length

[PATCH blktests] zbd/005: Limit block size to zone length

[Sean Anderson]

The block size must be smaller than the zone length, otherwise fio will
fail immediately.

Signed-off-by: Sean Anderson <seanga2@gmail.com>
---

 tests/zbd/005 | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tests/zbd/005 b/tests/zbd/005
index 4aa1ab5..3e1ded9 100755
--- a/tests/zbd/005
+++ b/tests/zbd/005
@@ -29,6 +29,7 @@ test_device() {
 	local -i zone_idx
 	local -i offset
 	local -i moaz
+	local -i block_size
 	local -a zbdmode=()
 
 	echo "Running ${TEST_NAME}"
@@ -38,6 +39,8 @@ test_device() {
 	zone_idx=$(_find_first_sequential_zone) || return $?
 	offset=$((ZONE_STARTS[zone_idx] * 512))
 	moaz=$(_test_dev_max_open_active_zones)
+	block_size=$(((ZONE_LENGTHS[zone_idx] > 512 ? \
+		       512 : ZONE_LENGTHS[zone_idx]) * 512))
 
 	# If the test target zone has smaller zone capacity than zone size,
 	# or if the test target device has max open/active zones limit, enable
@@ -53,7 +56,7 @@ test_device() {
 	: "${TIMEOUT:=30}"
 	FIO_PERF_FIELDS=("write io" "write iops")
 	_fio_perf --filename="${TEST_DEV}" --name zbdwo --rw=write --direct=1 \
-		  --ioengine=libaio --iodepth=128 --bs=256k \
+		  --ioengine=libaio --iodepth=128 --bs="${block_size}" \
 		  --offset="${offset}" "${zbdmode[@]}"
 
 	_put_blkzone_report
-- 
2.37.1

Re: [PATCH blktests] zbd/005: Limit block size to zone length

[Christoph Hellwig]

On Wed, Apr 23, 2025 at 12:49:57PM -0400, Sean Anderson wrote:
> The block size must be smaller than the zone length, otherwise fio will
> fail immediately.

In theory yes.  In practice such a zone size makes zero sense, and will
not work with any zoned file systems or other users.

So instead we should just warn about a silly zone size here instead
of trying to handle it.

Re: [PATCH blktests] zbd/005: Limit block size to zone length

[Shinichiro Kawasaki]

On Apr 24, 2025 / 01:09, Christoph Hellwig wrote:
> On Wed, Apr 23, 2025 at 12:49:57PM -0400, Sean Anderson wrote:
> > The block size must be smaller than the zone length, otherwise fio will
> > fail immediately.
> 
> In theory yes.  In practice such a zone size makes zero sense, and will
> not work with any zoned file systems or other users.
> 
> So instead we should just warn about a silly zone size here instead
> of trying to handle it.

As a similar idea, how about to skip the test case if the test target device's
zone size is too small?

Sean, could you try out the patch below? It will skip the test case for your
device, and you will not see the test case failing.

diff --git a/tests/zbd/005 b/tests/zbd/005
index 4aa1ab5..d23eabe 100755
--- a/tests/zbd/005
+++ b/tests/zbd/005
@@ -36,6 +36,13 @@ test_device() {
 	_get_blkzone_report "${TEST_DEV}" || return $?
 
 	zone_idx=$(_find_first_sequential_zone) || return $?
+
+	# Ensure the zone size is large enough for the fio command below
+	if ((ZONE_LENGTHS[zone_idx] < 512)); then
+		SKIP_REASONS+=("too small zone size")
+		return
+	fi
+
 	offset=$((ZONE_STARTS[zone_idx] * 512))
 	moaz=$(_test_dev_max_open_active_zones)
 

Re: [PATCH blktests] zbd/005: Limit block size to zone length

[Sean Anderson]

On 4/24/25 07:30, Shinichiro Kawasaki wrote:
> On Apr 24, 2025 / 01:09, Christoph Hellwig wrote:
>> On Wed, Apr 23, 2025 at 12:49:57PM -0400, Sean Anderson wrote:
>>> The block size must be smaller than the zone length, otherwise fio will
>>> fail immediately.
>>
>> In theory yes.  In practice such a zone size makes zero sense, and will
>> not work with any zoned file systems or other users.
>>
>> So instead we should just warn about a silly zone size here instead
>> of trying to handle it.
> 
> As a similar idea, how about to skip the test case if the test target device's
> zone size is too small?

Why would I want that? The test passes with an appropriate block size.

--Sean

Re: [PATCH blktests] zbd/005: Limit block size to zone length

[hch]

On Thu, Apr 24, 2025 at 09:56:11AM -0400, Sean Anderson wrote:
> > As a similar idea, how about to skip the test case if the test target device's
> > zone size is too small?
> 
> Why would I want that? The test passes with an appropriate block size.

Because this is a completely stupid device that can't actually be used
by any file system or storage system designed for zones.  Why would we
make a mess of our tests for a highschool science fair project?

Re: [PATCH blktests] zbd/005: Limit block size to zone length

[Sean Anderson]

On 4/24/25 10:06, hch@infradead.org wrote:
> On Thu, Apr 24, 2025 at 09:56:11AM -0400, Sean Anderson wrote:
>>> As a similar idea, how about to skip the test case if the test target device's
>>> zone size is too small?
>>
>> Why would I want that? The test passes with an appropriate block size.
> 
> Because this is a completely stupid device that can't actually be used
> by any file system or storage system designed for zones.  Why would we
> make a mess of our tests for a highschool science fair project?
> 

Because the test is trivially wrong.

--Sean

Re: [PATCH blktests] zbd/005: Limit block size to zone length

[hch]

On Thu, Apr 24, 2025 at 10:20:09AM -0400, Sean Anderson wrote:
> Because the test is trivially wrong.

I stronly disagree with that.  We also don't support < 512 byte LBA
sizes to give an example.

Yes, it would be nice to have a sanity check for that and reject it
early, but no one is going to rewrite tests to remove that "assumption".

Re: [PATCH blktests] zbd/005: Limit block size to zone length

[Damien Le Moal]

On 4/24/25 20:30, Shinichiro Kawasaki wrote:
> On Apr 24, 2025 / 01:09, Christoph Hellwig wrote:
>> On Wed, Apr 23, 2025 at 12:49:57PM -0400, Sean Anderson wrote:
>>> The block size must be smaller than the zone length, otherwise fio will
>>> fail immediately.
>>
>> In theory yes.  In practice such a zone size makes zero sense, and will
>> not work with any zoned file systems or other users.
>>
>> So instead we should just warn about a silly zone size here instead
>> of trying to handle it.
> 
> As a similar idea, how about to skip the test case if the test target device's
> zone size is too small?
> 
> Sean, could you try out the patch below? It will skip the test case for your
> device, and you will not see the test case failing.
> 
> diff --git a/tests/zbd/005 b/tests/zbd/005
> index 4aa1ab5..d23eabe 100755
> --- a/tests/zbd/005
> +++ b/tests/zbd/005
> @@ -36,6 +36,13 @@ test_device() {
>  	_get_blkzone_report "${TEST_DEV}" || return $?
>  
>  	zone_idx=$(_find_first_sequential_zone) || return $?
> +
> +	# Ensure the zone size is large enough for the fio command below
> +	if ((ZONE_LENGTHS[zone_idx] < 512)); then
> +		SKIP_REASONS+=("too small zone size")

Nit: "zone size too small" would be better.

> +		return
> +	fi
> +
>  	offset=$((ZONE_STARTS[zone_idx] * 512))
>  	moaz=$(_test_dev_max_open_active_zones)
>  
> 
> 


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH blktests] zbd/005: Limit block size to zone length

[Sean Anderson]

On 4/24/25 10:23, hch@infradead.org wrote:
> On Thu, Apr 24, 2025 at 10:20:09AM -0400, Sean Anderson wrote:
>> Because the test is trivially wrong.
> 
> I stronly disagree with that.  We also don't support < 512 byte LBA
> sizes to give an example.

fio already supports it

you are just passing a wrong parameter

< 512 LBA is a different case because there is so much both in kernel
and in userspace that assumes 512-byte granularity. But there is no
such deeply-ingrained assumption for zones. You just have to set the
parameter correctly.

Plus, smaller zones are more efficient at reducing write amplification,
in the same way as smaller block sizes.

If you really think such zone sizes should not be supported, then go
add such a restriction to all the zone standards.

> Yes, it would be nice to have a sanity check for that and reject it
> early, but no one is going to rewrite tests to remove that "assumption".

This assumption is very weak. It can easily be removed.

--Sean

Re: [PATCH blktests] zbd/005: Limit block size to zone length

[hch]

On Fri, Apr 25, 2025 at 12:04:39AM -0400, Sean Anderson wrote:
> and in userspace that assumes 512-byte granularity. But there is no
> such deeply-ingrained assumption for zones. You just have to set the
> parameter correctly.

There are everywhere in software actually using zones.  You still
haven't answered whay your intended use case is, btw.

> Plus, smaller zones are more efficient at reducing write amplification,
> in the same way as smaller block sizes.

No, they aren't.  If you zones are only a few kb you will waste a lot
of effort to actually track their state.

> If you really think such zone sizes should not be supported, then go
> add such a restriction to all the zone standards.

The zoned standards are extremely lax in what they allow, that is by
intent.  Actually software supports a lot less, and that for a good
reason,

> > Yes, it would be nice to have a sanity check for that and reject it
> > early, but no one is going to rewrite tests to remove that "assumption".
> 
> This assumption is very weak. It can easily be removed.

It can, but it's a really bad idea.

We're running in circles.  You are doing something very silly with
something not support in the kernel right now, without a use case
and are lecturing people who've done zoned software for years with
made up falsehoods.  That's not going very well.  Maybe your clever
scheme actually is better than what everyone has done for years, but
you'd better explain it very well and show how it's actually going
to work.

Re: [PATCH blktests] zbd/005: Limit block size to zone length

[Sean Anderson]

On 4/25/25 09:47, hch@infradead.org wrote:
> On Fri, Apr 25, 2025 at 12:04:39AM -0400, Sean Anderson wrote:
>> and in userspace that assumes 512-byte granularity. But there is no
>> such deeply-ingrained assumption for zones. You just have to set the
>> parameter correctly.
> 
> There are everywhere in software actually using zones.  You still
> haven't answered whay your intended use case is, btw.

I'm working on testing... I thought I would send a few bug fixes upstream in advance...

who knew I would get such a hostile response

>> Plus, smaller zones are more efficient at reducing write amplification,
>> in the same way as smaller block sizes.
> 
> No, they aren't.  If you zones are only a few kb you will waste a lot
> of effort to actually track their state.

The state is perhaps 4-8 bytes at most? And in any case it's proportional to
the number of zones. If you have a smaller drive you will naturally have smaller zones.

--Sean

Re: [PATCH blktests] zbd/005: Limit block size to zone length

[Keith Busch]

On Sat, Apr 26, 2025 at 01:23:08AM -0400, Sean Anderson wrote:
> On 4/25/25 09:47, hch@infradead.org wrote:
> > On Fri, Apr 25, 2025 at 12:04:39AM -0400, Sean Anderson wrote:
> > > and in userspace that assumes 512-byte granularity. But there is no
> > > such deeply-ingrained assumption for zones. You just have to set the
> > > parameter correctly.
> > 
> > There are everywhere in software actually using zones.  You still
> > haven't answered whay your intended use case is, btw.
> 
> I'm working on testing... I thought I would send a few bug fixes upstream in advance...
> 
> who knew I would get such a hostile response

The constraints you're suggesting fly in the face of all conventional
wisdom from developing zone devices. It would be a bit naive to think
proposing such a thing wouldn't pique some skepticism. Whether the zones
you're talking about are coming from SSD flash erase blocks or HDD
shingled tracks, both work on granularities orders of magnitude larger
than kilobytes.

If there's something else we don't know about, then it would be quite a
novel device that warrants further discussion. If no such device
actually exists, then it's a bit of a moot point whether anything
supports it or not.