[PATCH 0/2] scsi: scsi_debug: fix zoned write validation

[PATCH 0/2] scsi: scsi_debug: fix zoned write validation

[Niklas Cassel]

scsi_debug does not enforce all of the requirements that ZBC places on a
write to a sequential write required zone, and one command bypasses the
zone checks altogether. Both let the emulation accept a write that a
conforming device would terminate, and leave the zone in a state that
the kernel cannot work with.

Patch 1 adds the missing check that the ending LBA of a write falls on a
physical block boundary. Without it, a single logical block write at the
write pointer of a sequential zone is accepted on a device whose
physical block size is larger, and leaves a write pointer that is not a
multiple of the zone_write_granularity reported for the device. Nothing
can then write at that position at the granularity the kernel
advertises, and the zone can only be used again after being reset.

Patch 2 makes WRITE ATOMIC (16) go through the same zone validation as
every other write. resp_atomic_write() calls do_device_access()
directly, so an atomic write is accepted anywhere in a sequential zone
regardless of the write pointer, and the write pointer is never
advanced, which leaves REPORT ZONES describing something other than what
is on the medium.

The two are independent, but the order matters slightly: once patch 2
routes atomic writes through check_zbc_access_params(), the check added
by patch 1 applies to them as well.

Neither defect is reachable in a default configuration. Patch 1's check
is a no-op with the default physblk_exp=0, where the physical block size
equals the logical block size, and patch 2's path needs atomic_wr=1,
which defaults to off. That is presumably why both have gone unnoticed.

Tested on a zoned scsi_debug device with 512 byte logical blocks and a
4096 byte physical block:

  modprobe scsi_debug zbc=managed sector_size=512 physblk_exp=3 \
      zone_size_mb=8 dev_size_mb=128 zone_nr_conv=2 atomic_wr=1

Before the series, a one block WRITE(16) at a sequential zone's write
pointer completes with GOOD status and leaves the write pointer at LBA
0x18001, and a WRITE ATOMIC (16) is accepted both at and past the write
pointer without advancing it. After it, all three are terminated with
ILLEGAL REQUEST / UNALIGNED WRITE COMMAND, while an aligned eight block
WRITE ATOMIC (16) at the write pointer advances the write pointer by
eight blocks. Writes to conventional zones are unaffected.

Niklas Cassel (2):
  scsi: scsi_debug: Enforce physical block alignment of zoned writes
  scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

 drivers/scsi/scsi_debug.c | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

-- 
2.55.0

[PATCH 1/2] scsi: scsi_debug: Enforce physical block alignment of zoned writes

[Niklas Cassel]

ZBC-3 r06 (T10/BSR INCITS 579), 4.5.3.3.2 Write access pattern
requirements for sequential write required zones, states:

  The device server terminates with CHECK CONDITION status, with the
  sense key set to ILLEGAL REQUEST, and the additional sense code set
  to UNALIGNED WRITE COMMAND a write command, other than an entire
  medium write same command, that specifies:
    a) the starting LBA in a sequential write required zone set to a
       value that is not equal to the write pointer for that sequential
       write required zone; or
    b) an ending LBA that is not equal to the last logical block within
       a physical block (see SBC-5).

That is why sd_zbc_read_zones() sets the zone_write_granularity queue
limit to the physical block size of a host-managed device, exposing the
constraint to user space.

check_zbc_access_params() implements condition a) but not condition b):
it verifies that a write to a sequential write required zone starts at
the write pointer of the zone, but never validates the ending LBA. As a
consequence, when scsi_debug emulates a host-managed device whose
physical block size is larger than its logical block size, for instance
with zbc=managed sector_size=512 physblk_exp=3, a write of a single
logical block at the write pointer of a sequential zone is accepted and
advances the write pointer by one logical block. The write pointer is
then no longer a multiple of the zone_write_granularity reported for the
device, so nothing can write at it at the granularity that was
advertised, and the zone can only be used again after being reset.

Implement condition b) as well, with the same sense data as the write
pointer check, as the standard gives both conditions the same sense key
and additional sense code. The exclusion of an entire medium write same
command needs no special case: such a command spans the whole medium, so
it is already terminated with WRITE BOUNDARY VIOLATION by the preceding
check.

The check is placed in check_zbc_access_params(), which every command
that advances a zone write pointer reaches first: WRITE, WRITE SCATTERED
and WRITE SAME. Reads return earlier in the function and are unaffected.

Sequential write preferred zones, which are emulated for host-aware
devices with zbc=aware, are left alone: writes to them are not required
to be sequential, and Linux does not restrict the write granularity of
host-aware devices.

With the default physblk_exp=0, the physical block size equals the
logical block size and the new check is a no-op.

Assisted-by: LLM
Fixes: f0d1cf9378bd ("scsi: scsi_debug: Add ZBC zone commands")
Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
Tested with:

  modprobe scsi_debug zbc=managed sector_size=512 physblk_exp=3 \
      zone_size_mb=8 dev_size_mb=128 zone_nr_conv=2

Before this patch, a one logical block WRITE(16) at the write pointer of
an empty sequential write required zone completes with GOOD status and
leaves the write pointer at LBA 0x18001, which is not a multiple of the
4096 byte zone_write_granularity reported for the device. After it, the
same command is terminated with ILLEGAL REQUEST / UNALIGNED WRITE
COMMAND and the zone is left EMPTY, while an aligned eight block write
is still accepted.
---
 drivers/scsi/scsi_debug.c | 11 +++++++++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -3898,6 +3898,17 @@
 					UNALIGNED_WRITE_ASCQ);
 			return check_condition_result;
 		}
+		/*
+		 * Writes must end on a physical block boundary, that is, the
+		 * transfer length must be a multiple of the physical block
+		 * size.
+		 */
+		if (!IS_ALIGNED(lba + num, 1U << sdebug_physblk_exp)) {
+			mk_sense_buffer(scp, ILLEGAL_REQUEST,
+					LBA_OUT_OF_RANGE,
+					UNALIGNED_WRITE_ASCQ);
+			return check_condition_result;
+		}
 	}
 
 	/* Handle implicit open of closed and empty zones */
-- 
2.55.0

[PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

[Niklas Cassel]

WRITE ATOMIC (16) is a write command, so on a zoned device it is subject
to the access requirements of the zone that it addresses, and it advances
the write pointer of a sequential write required zone. See ZBC-3 r06
(T10/BSR INCITS 579), 4.5.3.3.2 Write access pattern requirements for
sequential write required zones.

resp_atomic_write() calls do_device_access() directly, without calling
check_device_access_params() first and without advancing the write
pointer afterwards. It is the only command that writes user data which
does not; WRITE, WRITE SCATTERED and WRITE SAME all go through
check_device_access_params(), which validates zone access for a zoned
device.

As a consequence, with zbc=managed atomic_wr=1, a WRITE ATOMIC (16) can
write anywhere within a sequential write required zone regardless of its
write pointer and zone condition, into a gap zone, or across a zone
boundary, and none of it is reflected in the zone state. The write
pointer is left where it was, so a subsequent REPORT ZONES does not
describe the data on the medium, and the next write at that write
pointer overwrites data that was written without error.

Validate the access and advance the write pointer the way
resp_write_dt0() does, holding the zone metadata write lock across both,
since the write pointer has to be read and updated atomically with
respect to other commands.

Assisted-by: LLM
Fixes: 84f3a3c01d70 ("scsi: scsi_debug: Atomic write support")
Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
Tested with:

  modprobe scsi_debug zbc=managed sector_size=512 physblk_exp=3 \
      zone_size_mb=8 dev_size_mb=128 zone_nr_conv=2 atomic_wr=1

issuing WRITE ATOMIC (16) with sg_raw. Before this patch, an eight block
atomic write at the write pointer of an empty sequential write required
zone completes with GOOD status and leaves the write pointer unchanged,
and one issued past the write pointer is accepted as well. After it, the
former advances the write pointer by eight blocks and the latter is
terminated with ILLEGAL REQUEST / UNALIGNED WRITE COMMAND.

A two block atomic write at the write pointer, which satisfies
atomic_wr_gran and atomic_wr_align but is smaller than the 4096 byte
physical block, is now rejected by the check added in the previous
patch. An atomic write to a conventional zone is unaffected.
---
 drivers/scsi/scsi_debug.c | 13 +++++++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -6043,7 +6043,24 @@
 		}
 	}
 
+	if (sdebug_dev_is_zoned(devip))
+		sdeb_meta_write_lock(sip);
+
+	ret = check_device_access_params(scp, lba, len, true);
+	if (ret) {
+		if (sdebug_dev_is_zoned(devip))
+			sdeb_meta_write_unlock(sip);
+		return ret;
+	}
+
 	ret = do_device_access(sip, scp, 0, lba, len, 0, true, true);
+
+	/* If ZBC zone then bump its write pointer */
+	if (sdebug_dev_is_zoned(devip)) {
+		zbc_inc_wp(devip, lba, len);
+		sdeb_meta_write_unlock(sip);
+	}
+
 	if (unlikely(ret == -1))
 		return DID_ERROR << 16;
 	if (unlikely(ret != len * sdebug_sector_size))
-- 
2.55.0

Re: [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] scsi: scsi_debug: zone write pointer incremented on failed ATOMIC WRITE
--

commit 9183d5d7f092b92218c3638f33edc6839086d9f3
Author: Niklas Cassel <cassel@kernel.org>

scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

WRITE ATOMIC (16) is a write command, so on a zoned device it is subject to
the access requirements of the zone that it addresses, and it advances the
write pointer of a sequential write required zone. This patch validates the
access and advances the write pointer holding the zone metadata write lock
across both operations.

> diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
> index 5a95b7cd7a44c..d52b1f762afb5 100644
> --- a/drivers/scsi/scsi_debug.c
> +++ b/drivers/scsi/scsi_debug.c
> @@ -6209,7 +6209,24 @@ static int resp_atomic_write(struct scsi_cmnd *scp,
[ ... ]
>  	ret = do_device_access(sip, scp, 0, lba, len, 0, true, true);
> +
> +	/* If ZBC zone then bump its write pointer */
> +	if (sdebug_dev_is_zoned(devip)) {
> +		zbc_inc_wp(devip, lba, len);

[Severity: Medium]
Does this code advance the write pointer even if do_device_access() fails?

If a command like WRITE ATOMIC (16) is submitted with an invalid DMA
direction (e.g., DMA_FROM_DEVICE via SG_IO) or a truncated scatter-gather
list, do_device_access() can return -1 or a short length.

Because the write pointer in resp_atomic_write() is incremented before
checking the return value of do_device_access(), the mock device's internal
zone state could become out-of-sync with the simulated physical medium.
This could cause subsequent valid writes to be incorrectly rejected with
UNALIGNED WRITE COMMAND.

> +		sdeb_meta_write_unlock(sip);
> +	}
> +
>  	if (unlikely(ret == -1))
>  		return DID_ERROR << 16;
>  	if (unlikely(ret != len * sdebug_sector_size))
>  		return DID_ERROR << 16;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260917084553.559765-4-cassel@kernel.org?part=2

Re: [PATCH 1/2] scsi: scsi_debug: Enforce physical block alignment of zoned writes

[Damien Le Moal]

On 2026/09/17 15:45, Niklas Cassel wrote:
> ZBC-3 r06 (T10/BSR INCITS 579), 4.5.3.3.2 Write access pattern
> requirements for sequential write required zones, states:
> 
>   The device server terminates with CHECK CONDITION status, with the
>   sense key set to ILLEGAL REQUEST, and the additional sense code set
>   to UNALIGNED WRITE COMMAND a write command, other than an entire
>   medium write same command, that specifies:
>     a) the starting LBA in a sequential write required zone set to a
>        value that is not equal to the write pointer for that sequential
>        write required zone; or
>     b) an ending LBA that is not equal to the last logical block within
>        a physical block (see SBC-5).
> 
> That is why sd_zbc_read_zones() sets the zone_write_granularity queue
> limit to the physical block size of a host-managed device, exposing the
> constraint to user space.
> 
> check_zbc_access_params() implements condition a) but not condition b):
> it verifies that a write to a sequential write required zone starts at
> the write pointer of the zone, but never validates the ending LBA. As a
> consequence, when scsi_debug emulates a host-managed device whose
> physical block size is larger than its logical block size, for instance
> with zbc=managed sector_size=512 physblk_exp=3, a write of a single
> logical block at the write pointer of a sequential zone is accepted and
> advances the write pointer by one logical block. The write pointer is
> then no longer a multiple of the zone_write_granularity reported for the
> device, so nothing can write at it at the granularity that was
> advertised, and the zone can only be used again after being reset.
> 
> Implement condition b) as well, with the same sense data as the write
> pointer check, as the standard gives both conditions the same sense key
> and additional sense code. The exclusion of an entire medium write same
> command needs no special case: such a command spans the whole medium, so
> it is already terminated with WRITE BOUNDARY VIOLATION by the preceding
> check.
> 
> The check is placed in check_zbc_access_params(), which every command
> that advances a zone write pointer reaches first: WRITE, WRITE SCATTERED
> and WRITE SAME. Reads return earlier in the function and are unaffected.
> 
> Sequential write preferred zones, which are emulated for host-aware
> devices with zbc=aware, are left alone: writes to them are not required
> to be sequential, and Linux does not restrict the write granularity of
> host-aware devices.
> 
> With the default physblk_exp=0, the physical block size equals the
> logical block size and the new check is a no-op.
> 
> Assisted-by: LLM
> Fixes: f0d1cf9378bd ("scsi: scsi_debug: Add ZBC zone commands")
> Signed-off-by: Niklas Cassel <cassel@kernel.org>

Looks good, but that will be another conflict with linux-next...
May be rebase the fix on scsi-staging and let's push it to 7.4 instead?

Either way,

Reviewed-by: Damien Le Moal <dlemoal@kernel.org>


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

[Damien Le Moal]

On 2026/09/17 15:45, Niklas Cassel wrote:
> WRITE ATOMIC (16) is a write command, so on a zoned device it is subject
> to the access requirements of the zone that it addresses, and it advances
> the write pointer of a sequential write required zone. See ZBC-3 r06
> (T10/BSR INCITS 579), 4.5.3.3.2 Write access pattern requirements for
> sequential write required zones.
> 
> resp_atomic_write() calls do_device_access() directly, without calling
> check_device_access_params() first and without advancing the write
> pointer afterwards. It is the only command that writes user data which
> does not; WRITE, WRITE SCATTERED and WRITE SAME all go through
> check_device_access_params(), which validates zone access for a zoned
> device.
> 
> As a consequence, with zbc=managed atomic_wr=1, a WRITE ATOMIC (16) can
> write anywhere within a sequential write required zone regardless of its
> write pointer and zone condition, into a gap zone, or across a zone
> boundary, and none of it is reflected in the zone state. The write
> pointer is left where it was, so a subsequent REPORT ZONES does not
> describe the data on the medium, and the next write at that write
> pointer overwrites data that was written without error.
> 
> Validate the access and advance the write pointer the way
> resp_write_dt0() does, holding the zone metadata write lock across both,
> since the write pointer has to be read and updated atomically with
> respect to other commands.
> 
> Assisted-by: LLM
> Fixes: 84f3a3c01d70 ("scsi: scsi_debug: Atomic write support")
> Signed-off-by: Niklas Cassel <cassel@kernel.org>
> ---
> Tested with:
> 
>   modprobe scsi_debug zbc=managed sector_size=512 physblk_exp=3 \
>       zone_size_mb=8 dev_size_mb=128 zone_nr_conv=2 atomic_wr=1
> 
> issuing WRITE ATOMIC (16) with sg_raw. Before this patch, an eight block
> atomic write at the write pointer of an empty sequential write required
> zone completes with GOOD status and leaves the write pointer unchanged,
> and one issued past the write pointer is accepted as well. After it, the
> former advances the write pointer by eight blocks and the latter is
> terminated with ILLEGAL REQUEST / UNALIGNED WRITE COMMAND.
> 
> A two block atomic write at the write pointer, which satisfies
> atomic_wr_gran and atomic_wr_align but is smaller than the 4096 byte
> physical block, is now rejected by the check added in the previous
> patch. An atomic write to a conventional zone is unaffected.
> ---
>  drivers/scsi/scsi_debug.c | 13 +++++++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
> --- a/drivers/scsi/scsi_debug.c
> +++ b/drivers/scsi/scsi_debug.c
> @@ -6043,7 +6043,24 @@
>  		}
>  	}
>  
> +	if (sdebug_dev_is_zoned(devip))
> +		sdeb_meta_write_lock(sip);
> +
> +	ret = check_device_access_params(scp, lba, len, true);
> +	if (ret) {
> +		if (sdebug_dev_is_zoned(devip))
> +			sdeb_meta_write_unlock(sip);
> +		return ret;
> +	}
> +
>  	ret = do_device_access(sip, scp, 0, lba, len, 0, true, true);
> +
> +	/* If ZBC zone then bump its write pointer */
> +	if (sdebug_dev_is_zoned(devip)) {
> +		zbc_inc_wp(devip, lba, len);
> +		sdeb_meta_write_unlock(sip);
> +	}

Shouldn't this go after the error checks below?
If the command failed, you do not want to advance the wp...

> +
>  	if (unlikely(ret == -1))
>  		return DID_ERROR << 16;
>  	if (unlikely(ret != len * sdebug_sector_size))


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

[Niklas Cassel]

On Thu, Sep 17, 2026 at 09:00:21AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] scsi: scsi_debug: zone write pointer incremented on failed ATOMIC WRITE
> --
> 
> commit 9183d5d7f092b92218c3638f33edc6839086d9f3
> Author: Niklas Cassel <cassel@kernel.org>
> 
> scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)
> 
> WRITE ATOMIC (16) is a write command, so on a zoned device it is subject to
> the access requirements of the zone that it addresses, and it advances the
> write pointer of a sequential write required zone. This patch validates the
> access and advances the write pointer holding the zone metadata write lock
> across both operations.
> 
> > diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
> > index 5a95b7cd7a44c..d52b1f762afb5 100644
> > --- a/drivers/scsi/scsi_debug.c
> > +++ b/drivers/scsi/scsi_debug.c
> > @@ -6209,7 +6209,24 @@ static int resp_atomic_write(struct scsi_cmnd *scp,
> [ ... ]
> >  	ret = do_device_access(sip, scp, 0, lba, len, 0, true, true);
> > +
> > +	/* If ZBC zone then bump its write pointer */
> > +	if (sdebug_dev_is_zoned(devip)) {
> > +		zbc_inc_wp(devip, lba, len);
> 
> [Severity: Medium]
> Does this code advance the write pointer even if do_device_access() fails?
> 
> If a command like WRITE ATOMIC (16) is submitted with an invalid DMA
> direction (e.g., DMA_FROM_DEVICE via SG_IO) or a truncated scatter-gather
> list, do_device_access() can return -1 or a short length.
> 
> Because the write pointer in resp_atomic_write() is incremented before
> checking the return value of do_device_access(), the mock device's internal
> zone state could become out-of-sync with the simulated physical medium.
> This could cause subsequent valid writes to be incorrectly rejected with
> UNALIGNED WRITE COMMAND.

That is how resp_write_dt0() and all other write functions is scsi_debug is
implemented.

That said, I agree that it looks suboptimal...

I can write prep-patch that cleans up all the write functions to only
advance the WP when do_device_access() succeeds.


Kind regards,
Niklas

Re: [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

[John Garry]

On 9/17/26 09:45, Niklas Cassel wrote:

So far we have not considered atomic writes for zoned devices - do 
devices which support both technologies exist? Or is this just hypothetical?

> WRITE ATOMIC (16) is a write command, so on a zoned device it is subject
> to the access requirements of the zone that it addresses, and it advances
> the write pointer of a sequential write required zone. See ZBC-3 r06
> (T10/BSR INCITS 579), 4.5.3.3.2 Write access pattern requirements for
> sequential write required zones.
> 
> resp_atomic_write() calls do_device_access() directly, without calling
> check_device_access_params() first and without advancing the write
> pointer afterwards. It is the only command that writes user data which
> does not; WRITE, WRITE SCATTERED and WRITE SAME all go through
> check_device_access_params(), which validates zone access for a zoned
> device.
> 
> As a consequence, with zbc=managed atomic_wr=1, a WRITE ATOMIC (16) can
> write anywhere within a sequential write required zone regardless of its
> write pointer and zone condition, into a gap zone, or across a zone
> boundary, and none of it is reflected in the zone state. The write
> pointer is left where it was, so a subsequent REPORT ZONES does not
> describe the data on the medium, and the next write at that write
> pointer overwrites data that was written without error.
> 
> Validate the access and advance the write pointer the way
> resp_write_dt0() does, holding the zone metadata write lock across both,
> since the write pointer has to be read and updated atomically with
> respect to other commands.
> 
> Assisted-by: LLM
> Fixes: 84f3a3c01d70 ("scsi: scsi_debug: Atomic write support")
> Signed-off-by: Niklas Cassel <cassel@kernel.org>
> ---
> Tested with:
> 
>    modprobe scsi_debug zbc=managed sector_size=512 physblk_exp=3 \
>        zone_size_mb=8 dev_size_mb=128 zone_nr_conv=2 atomic_wr=1
> 
> issuing WRITE ATOMIC (16) with sg_raw. Before this patch, an eight block
> atomic write at the write pointer of an empty sequential write required
> zone completes with GOOD status and leaves the write pointer unchanged,
> and one issued past the write pointer is accepted as well. After it, the
> former advances the write pointer by eight blocks and the latter is
> terminated with ILLEGAL REQUEST / UNALIGNED WRITE COMMAND.
> 
> A two block atomic write at the write pointer, which satisfies
> atomic_wr_gran and atomic_wr_align but is smaller than the 4096 byte
> physical block, is now rejected by the check added in the previous
> patch. An atomic write to a conventional zone is unaffected.
> ---
>   drivers/scsi/scsi_debug.c | 13 +++++++++++++++++
>   1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
> --- a/drivers/scsi/scsi_debug.c
> +++ b/drivers/scsi/scsi_debug.c
> @@ -6043,7 +6043,24 @@
>   		}
>   	}
>   
> +	if (sdebug_dev_is_zoned(devip))
> +		sdeb_meta_write_lock(sip);
> +
> +	ret = check_device_access_params(scp, lba, len, true);
> +	if (ret) {
> +		if (sdebug_dev_is_zoned(devip))
> +			sdeb_meta_write_unlock(sip);
> +		return ret;
> +	}
> +
>   	ret = do_device_access(sip, scp, 0, lba, len, 0, true, true);
> +
> +	/* If ZBC zone then bump its write pointer */
> +	if (sdebug_dev_is_zoned(devip)) {
> +		zbc_inc_wp(devip, lba, len);
> +		sdeb_meta_write_unlock(sip);
> +	}
> +
>   	if (unlikely(ret == -1))
>   		return DID_ERROR << 16;
>   	if (unlikely(ret != len * sdebug_sector_size))

Re: [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

[Niklas Cassel]

On Thu, Sep 17, 2026 at 10:38:30AM +0100, John Garry wrote:
> On 9/17/26 09:45, Niklas Cassel wrote:
> 
> So far we have not considered atomic writes for zoned devices
> - do devices which support both technologies exist? Or is
> this just hypothetical?

If the specs allow it, someone might build it.

I don't see why someone would not want to build a device that supports both,
as they are both really nice features :)


Kind regards,
Niklas

Re: [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

[John Garry]

On 9/17/26 10:56, Niklas Cassel wrote:
> On Thu, Sep 17, 2026 at 10:38:30AM +0100, John Garry wrote:
>> On 9/17/26 09:45, Niklas Cassel wrote:
>>
>> So far we have not considered atomic writes for zoned devices
>> - do devices which support both technologies exist? Or is
>> this just hypothetical?
> If the specs allow it, someone might build it.

Sure, but do they (allow it)? atomic writes have specific alignment and 
granularity rules - how does that play with zoned devices?

I would need to check the specs more on this..

> 
> I don't see why someone would not want to build a device that supports both,
> as they are both really nice features 🙂

Re: [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

[Niklas Cassel]

On Thu, Sep 17, 2026 at 11:26:45AM +0100, John Garry wrote:
> On 9/17/26 10:56, Niklas Cassel wrote:
> > On Thu, Sep 17, 2026 at 10:38:30AM +0100, John Garry wrote:
> > > On 9/17/26 09:45, Niklas Cassel wrote:
> > > 
> > > So far we have not considered atomic writes for zoned devices
> > > - do devices which support both technologies exist? Or is
> > > this just hypothetical?
> > If the specs allow it, someone might build it.
> 
> Sure, but do they (allow it)? atomic writes have specific
> alignment and granularity rules - how does that play with
> zoned devices?
> 
> I would need to check the specs more on this..

I haven't been able to find anything that disallows it.

Trying to parse the specs with the help of LLM:

""
WRITE ATOMIC (16) is a write command as far as ZBC is concerned, so on a
zoned device it is subject to the access requirements of the zone that it
addresses, and it advances the write pointer of a sequential write
required zone.
Neither standard says so directly, but the definitions leave no room for
anything else. SBC-6 r02 defines an atomic write operation as a "process
by which a device server performs a write operation that is either
completed in its entirety or has no effects on stored logical block
data" (3.1.9), and an atomic write command as a "command that performs
one or more atomic write operations" (3.1.8). ZBC-3 r06 in turn defines
a write operation as a "write operation as described in SBC-5 with the
additional requirements described in this standard" (3.1.62), and a
write command as a "command that requests write operations" (3.1.61).
WRITE ATOMIC (16) therefore falls under 4.5.3.3.2 Write access pattern
requirements for sequential write required zones, exactly as WRITE (16)
does.
""

Right now, I don't see why WRITE ATOMIC should not be allowed on a ZBC
drive.


Kind regards,
Niklas

Re: [PATCH 1/2] scsi: scsi_debug: Enforce physical block alignment of zoned writes

[Niklas Cassel]

On Thu, Sep 17, 2026 at 04:05:54PM +0700, Damien Le Moal wrote:
> On 2026/09/17 15:45, Niklas Cassel wrote:
> > ZBC-3 r06 (T10/BSR INCITS 579), 4.5.3.3.2 Write access pattern
> > requirements for sequential write required zones, states:
> > 
> >   The device server terminates with CHECK CONDITION status, with the
> >   sense key set to ILLEGAL REQUEST, and the additional sense code set
> >   to UNALIGNED WRITE COMMAND a write command, other than an entire
> >   medium write same command, that specifies:
> >     a) the starting LBA in a sequential write required zone set to a
> >        value that is not equal to the write pointer for that sequential
> >        write required zone; or
> >     b) an ending LBA that is not equal to the last logical block within
> >        a physical block (see SBC-5).
> > 
> > That is why sd_zbc_read_zones() sets the zone_write_granularity queue
> > limit to the physical block size of a host-managed device, exposing the
> > constraint to user space.
> > 
> > check_zbc_access_params() implements condition a) but not condition b):
> > it verifies that a write to a sequential write required zone starts at
> > the write pointer of the zone, but never validates the ending LBA. As a
> > consequence, when scsi_debug emulates a host-managed device whose
> > physical block size is larger than its logical block size, for instance
> > with zbc=managed sector_size=512 physblk_exp=3, a write of a single
> > logical block at the write pointer of a sequential zone is accepted and
> > advances the write pointer by one logical block. The write pointer is
> > then no longer a multiple of the zone_write_granularity reported for the
> > device, so nothing can write at it at the granularity that was
> > advertised, and the zone can only be used again after being reset.
> > 
> > Implement condition b) as well, with the same sense data as the write
> > pointer check, as the standard gives both conditions the same sense key
> > and additional sense code. The exclusion of an entire medium write same
> > command needs no special case: such a command spans the whole medium, so
> > it is already terminated with WRITE BOUNDARY VIOLATION by the preceding
> > check.
> > 
> > The check is placed in check_zbc_access_params(), which every command
> > that advances a zone write pointer reaches first: WRITE, WRITE SCATTERED
> > and WRITE SAME. Reads return earlier in the function and are unaffected.
> > 
> > Sequential write preferred zones, which are emulated for host-aware
> > devices with zbc=aware, are left alone: writes to them are not required
> > to be sequential, and Linux does not restrict the write granularity of
> > host-aware devices.
> > 
> > With the default physblk_exp=0, the physical block size equals the
> > logical block size and the new check is a no-op.
> > 
> > Assisted-by: LLM
> > Fixes: f0d1cf9378bd ("scsi: scsi_debug: Add ZBC zone commands")
> > Signed-off-by: Niklas Cassel <cassel@kernel.org>
> 
> Looks good, but that will be another conflict with linux-next...
> May be rebase the fix on scsi-staging and let's push it to 7.4 instead?

Considering that the fixes are only for a moduled used for debug,
I can do that.

Will rebase on mkp/7.4/scsi-staging


Kind regards,
Niklas

Re: [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

[John Garry]

On 9/17/26 11:35, Niklas Cassel wrote:
> On Thu, Sep 17, 2026 at 11:26:45AM +0100, John Garry wrote:
>> On 9/17/26 10:56, Niklas Cassel wrote:
>>> On Thu, Sep 17, 2026 at 10:38:30AM +0100, John Garry wrote:
>>>> On 9/17/26 09:45, Niklas Cassel wrote:
>>>>
>>>> So far we have not considered atomic writes for zoned devices
>>>> - do devices which support both technologies exist? Or is
>>>> this just hypothetical?
>>> If the specs allow it, someone might build it.
>>
>> Sure, but do they (allow it)? atomic writes have specific
>> alignment and granularity rules - how does that play with
>> zoned devices?
>>
>> I would need to check the specs more on this..
> 
> I haven't been able to find anything that disallows it.
> 
> Trying to parse the specs with the help of LLM:
> 
> ""
> WRITE ATOMIC (16) is a write command as far as ZBC is concerned, so on a
> zoned device it is subject to the access requirements of the zone that it
> addresses, and it advances the write pointer of a sequential write
> required zone.
> Neither standard says so directly, but the definitions leave no room for
> anything else. SBC-6 r02 defines an atomic write operation as a "process
> by which a device server performs a write operation that is either
> completed in its entirety or has no effects on stored logical block
> data" (3.1.9), and an atomic write command as a "command that performs
> one or more atomic write operations" (3.1.8). ZBC-3 r06 in turn defines
> a write operation as a "write operation as described in SBC-5 with the
> additional requirements described in this standard" (3.1.62), and a
> write command as a "command that requests write operations" (3.1.61).
> WRITE ATOMIC (16) therefore falls under 4.5.3.3.2 Write access pattern
> requirements for sequential write required zones, exactly as WRITE (16)
> does.
> ""
> 
> Right now, I don't see why WRITE ATOMIC should not be allowed on a ZBC
> drive.
> 
> 
So what happens when the write pointer is not aligned with Atomic 
alignment? Are atomic writes just not permitted in that scenario?

Re: [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

[Niklas Cassel]

Hello John,

On 17 September 2026 17:42:28 CEST, John Garry <john.garry@linux.dev> wrote:
>On 9/17/26 11:35, Niklas Cassel wrote:
>> On Thu, Sep 17, 2026 at 11:26:45AM +0100, John Garry wrote:
>>> On 9/17/26 10:56, Niklas Cassel wrote:
>>>> On Thu, Sep 17, 2026 at 10:38:30AM +0100, John Garry wrote:
>>>>> On 9/17/26 09:45, Niklas Cassel wrote:
>>>>> 
>>>>> So far we have not considered atomic writes for zoned devices
>>>>> - do devices which support both technologies exist? Or is
>>>>> this just hypothetical?
>>>> If the specs allow it, someone might build it.
>>> 
>>> Sure, but do they (allow it)? atomic writes have specific
>>> alignment and granularity rules - how does that play with
>>> zoned devices?
>>> 
>>> I would need to check the specs more on this..
>> 
>> I haven't been able to find anything that disallows it.
>> 
>> Trying to parse the specs with the help of LLM:
>> 
>> ""
>> WRITE ATOMIC (16) is a write command as far as ZBC is concerned, so on a
>> zoned device it is subject to the access requirements of the zone that it
>> addresses, and it advances the write pointer of a sequential write
>> required zone.
>> Neither standard says so directly, but the definitions leave no room for
>> anything else. SBC-6 r02 defines an atomic write operation as a "process
>> by which a device server performs a write operation that is either
>> completed in its entirety or has no effects on stored logical block
>> data" (3.1.9), and an atomic write command as a "command that performs
>> one or more atomic write operations" (3.1.8). ZBC-3 r06 in turn defines
>> a write operation as a "write operation as described in SBC-5 with the
>> additional requirements described in this standard" (3.1.62), and a
>> write command as a "command that requests write operations" (3.1.61).
>> WRITE ATOMIC (16) therefore falls under 4.5.3.3.2 Write access pattern
>> requirements for sequential write required zones, exactly as WRITE (16)
>> does.
>> ""
>> 
>> Right now, I don't see why WRITE ATOMIC should not be allowed on a ZBC
>> drive.
>> 
>> 
>So what happens when the write pointer is not aligned with Atomic alignment? Are atomic writes just not permitted in that scenario?


You are the expert when it comes to atomic writes.

But I would imagine that a device that implements both WRITE ATOMIC and ZBC
would set the atomic alignment to the physical block size.

That way the write pointer in sequential write required zones would always be aligned to both.

I/Os too larger than MAXIMUM ATOMIC TRANSFER LENGTH could be invalid for WRITE ATOMIC, but could be valid for regular writes.

Anyway, I will probably just drop this patch when I respin, since Damien did not fancy it.

I will keep the fix that ensures that we mark the blocks written by WRITE ATOMIC are marked as mapped:
https://lore.kernel.org/linux-scsi/12d01f4b-4d9f-4079-908d-ede50f7a28b4@kernel.org/


Kind regards,
Niklas

Re: [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

[John Garry]

On 9/17/26 17:10, Niklas Cassel wrote:
>>> Right now, I don't see why WRITE ATOMIC should not be allowed on a ZBC
>>> drive.
>>>
>>>
>> So what happens when the write pointer is not aligned with Atomic alignment? Are atomic writes just not permitted in that scenario?
> 
> You are the expert when it comes to atomic writes.
> 
> But I would imagine that a device that implements both WRITE ATOMIC and ZBC
> would set the atomic alignment to the physical block size.

Sure, that sounds like a sane implementation. But there is nothing in 
the SCSI spec which mandates this (as far as I remember).

Maybe I am just being pedantic here in expecting the SCSI specs to be 
specific about interoperability of these two features.

> 
> That way the write pointer in sequential write required zones would always be aligned to both.
> 
> I/Os too larger than MAXIMUM ATOMIC TRANSFER LENGTH could be invalid for WRITE ATOMIC, but could be valid for regular writes.
> 
> Anyway, I will probably just drop this patch when I respin, since Damien did not fancy it.
> 
> I will keep the fix that ensures that we mark the blocks written by WRITE ATOMIC are marked as mapped:
> https://lore.kernel.org/linux-scsi/12d01f4b-4d9f-4079-908d- 
> ede50f7a28b4@kernel.org/

ok, I'll check it.

Thanks!

Re: [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

[Niklas Cassel]

On Thu, Sep 17, 2026 at 06:10:11PM +0200, Niklas Cassel wrote:
> Hello John,
> 
> On 17 September 2026 17:42:28 CEST, John Garry <john.garry@linux.dev> wrote:
> >On 9/17/26 11:35, Niklas Cassel wrote:
> >> On Thu, Sep 17, 2026 at 11:26:45AM +0100, John Garry wrote:
> >>> On 9/17/26 10:56, Niklas Cassel wrote:
> >>>> On Thu, Sep 17, 2026 at 10:38:30AM +0100, John Garry wrote:
> >>>>> On 9/17/26 09:45, Niklas Cassel wrote:
> >>>>> 
> >>>>> So far we have not considered atomic writes for zoned devices
> >>>>> - do devices which support both technologies exist? Or is
> >>>>> this just hypothetical?
> >>>> If the specs allow it, someone might build it.
> >>> 
> >>> Sure, but do they (allow it)? atomic writes have specific
> >>> alignment and granularity rules - how does that play with
> >>> zoned devices?
> >>> 
> >>> I would need to check the specs more on this..
> >> 
> >> I haven't been able to find anything that disallows it.
> >> 
> >> Trying to parse the specs with the help of LLM:
> >> 
> >> ""
> >> WRITE ATOMIC (16) is a write command as far as ZBC is concerned, so on a
> >> zoned device it is subject to the access requirements of the zone that it
> >> addresses, and it advances the write pointer of a sequential write
> >> required zone.
> >> Neither standard says so directly, but the definitions leave no room for
> >> anything else. SBC-6 r02 defines an atomic write operation as a "process
> >> by which a device server performs a write operation that is either
> >> completed in its entirety or has no effects on stored logical block
> >> data" (3.1.9), and an atomic write command as a "command that performs
> >> one or more atomic write operations" (3.1.8). ZBC-3 r06 in turn defines
> >> a write operation as a "write operation as described in SBC-5 with the
> >> additional requirements described in this standard" (3.1.62), and a
> >> write command as a "command that requests write operations" (3.1.61).
> >> WRITE ATOMIC (16) therefore falls under 4.5.3.3.2 Write access pattern
> >> requirements for sequential write required zones, exactly as WRITE (16)
> >> does.
> >> ""
> >> 
> >> Right now, I don't see why WRITE ATOMIC should not be allowed on a ZBC
> >> drive.
> >> 
> >> 
> >So what happens when the write pointer is not aligned with Atomic alignment? Are atomic writes just not permitted in that scenario?
> 
> 
> You are the expert when it comes to atomic writes.
> 
> But I would imagine that a device that implements both WRITE ATOMIC and ZBC
> would set the atomic alignment to the physical block size.
> 
> That way the write pointer in sequential write required zones would always be aligned to both.

The above is true for sequential write required zones.
For SWR zones: The write pointer will always be aligned to the physical block
size. (Regardless if physical block size > logical block size, or PBS == LBS).

For conventional zones, when physical block size > logical block size:
The write pointer can be aligned to logical block size.
Since for conventional zones, the write is implemented using a read modify
write.


Thus for conventional zones, if the WP is aligned to LBS, but not PBS,
I think it would make sense that a WRITE ATOMIC would fail with:

""
If the starting LBA of an atomic write command does not meet the requirements
of the ATOMIC ALIGNMENT field (see 6.6.4), then the device server shall
terminate the command with CHECK CONDITION status with the sense key set to
ILLEGAL REQUEST and the additional sense code set to INVALID FIELD IN CDB.
""

Considering that a write < physical block size is implemented as a RMW on
conventional zones, so the write cannot be done atomically.

Yet, a normal (non-atomic) write, at the same WP, would succeed (because it
would do a RMW).

But this is just me stating what I think would be the logical implementation.


Kind regards,
Niklas

Re: [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

[Damien Le Moal]

On 2026/09/18 0:37, Niklas Cassel wrote:
> On Thu, Sep 17, 2026 at 06:10:11PM +0200, Niklas Cassel wrote:
>> Hello John,
>>
>> On 17 September 2026 17:42:28 CEST, John Garry <john.garry@linux.dev> wrote:
>>> On 9/17/26 11:35, Niklas Cassel wrote:
>>>> On Thu, Sep 17, 2026 at 11:26:45AM +0100, John Garry wrote:
>>>>> On 9/17/26 10:56, Niklas Cassel wrote:
>>>>>> On Thu, Sep 17, 2026 at 10:38:30AM +0100, John Garry wrote:
>>>>>>> On 9/17/26 09:45, Niklas Cassel wrote:
>>>>>>>
>>>>>>> So far we have not considered atomic writes for zoned devices
>>>>>>> - do devices which support both technologies exist? Or is
>>>>>>> this just hypothetical?
>>>>>> If the specs allow it, someone might build it.
>>>>>
>>>>> Sure, but do they (allow it)? atomic writes have specific
>>>>> alignment and granularity rules - how does that play with
>>>>> zoned devices?
>>>>>
>>>>> I would need to check the specs more on this..
>>>>
>>>> I haven't been able to find anything that disallows it.
>>>>
>>>> Trying to parse the specs with the help of LLM:
>>>>
>>>> ""
>>>> WRITE ATOMIC (16) is a write command as far as ZBC is concerned, so on a
>>>> zoned device it is subject to the access requirements of the zone that it
>>>> addresses, and it advances the write pointer of a sequential write
>>>> required zone.
>>>> Neither standard says so directly, but the definitions leave no room for
>>>> anything else. SBC-6 r02 defines an atomic write operation as a "process
>>>> by which a device server performs a write operation that is either
>>>> completed in its entirety or has no effects on stored logical block
>>>> data" (3.1.9), and an atomic write command as a "command that performs
>>>> one or more atomic write operations" (3.1.8). ZBC-3 r06 in turn defines
>>>> a write operation as a "write operation as described in SBC-5 with the
>>>> additional requirements described in this standard" (3.1.62), and a
>>>> write command as a "command that requests write operations" (3.1.61).
>>>> WRITE ATOMIC (16) therefore falls under 4.5.3.3.2 Write access pattern
>>>> requirements for sequential write required zones, exactly as WRITE (16)
>>>> does.
>>>> ""
>>>>
>>>> Right now, I don't see why WRITE ATOMIC should not be allowed on a ZBC
>>>> drive.
>>>>
>>>>
>>> So what happens when the write pointer is not aligned with Atomic alignment? Are atomic writes just not permitted in that scenario?
>>
>>
>> You are the expert when it comes to atomic writes.
>>
>> But I would imagine that a device that implements both WRITE ATOMIC and ZBC
>> would set the atomic alignment to the physical block size.
>>
>> That way the write pointer in sequential write required zones would always be aligned to both.
> 
> The above is true for sequential write required zones.
> For SWR zones: The write pointer will always be aligned to the physical block
> size. (Regardless if physical block size > logical block size, or PBS == LBS).
> 
> For conventional zones, when physical block size > logical block size:
> The write pointer can be aligned to logical block size.
> Since for conventional zones, the write is implemented using a read modify
> write.
> 
> 
> Thus for conventional zones, if the WP is aligned to LBS, but not PBS,
> I think it would make sense that a WRITE ATOMIC would fail with:
> 
> ""
> If the starting LBA of an atomic write command does not meet the requirements
> of the ATOMIC ALIGNMENT field (see 6.6.4), then the device server shall
> terminate the command with CHECK CONDITION status with the sense key set to
> ILLEGAL REQUEST and the additional sense code set to INVALID FIELD IN CDB.
> ""
> 
> Considering that a write < physical block size is implemented as a RMW on
> conventional zones, so the write cannot be done atomically.
> 
> Yet, a normal (non-atomic) write, at the same WP, would succeed (because it
> would do a RMW).
> 
> But this is just me stating what I think would be the logical implementation.

As I commented already, I think we should *not* allow for atomic write on ZBC in
scsi_debug. The reason is that as discussed here, implementation of the combined
features is not as simple as it seems, and since there are no SMR drives out
there supporting atomic writes, I do not want to give users false hopes with
scsi debug :)

Let's make atomic writes and ZBC emulation mutually exclusive.


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

[Niklas Cassel]

On Fri, Sep 18, 2026 at 09:27:10AM +0700, Damien Le Moal wrote:
> > The above is true for sequential write required zones.
> > For SWR zones: The write pointer will always be aligned to the physical block
> > size. (Regardless if physical block size > logical block size, or PBS == LBS).
> > 
> > For conventional zones, when physical block size > logical block size:
> > The write pointer can be aligned to logical block size.
> > Since for conventional zones, the write is implemented using a read modify
> > write.
> > 
> > 
> > Thus for conventional zones, if the WP is aligned to LBS, but not PBS,
> > I think it would make sense that a WRITE ATOMIC would fail with:
> > 
> > ""
> > If the starting LBA of an atomic write command does not meet the requirements
> > of the ATOMIC ALIGNMENT field (see 6.6.4), then the device server shall
> > terminate the command with CHECK CONDITION status with the sense key set to
> > ILLEGAL REQUEST and the additional sense code set to INVALID FIELD IN CDB.
> > ""
> > 
> > Considering that a write < physical block size is implemented as a RMW on
> > conventional zones, so the write cannot be done atomically.
> > 
> > Yet, a normal (non-atomic) write, at the same WP, would succeed (because it
> > would do a RMW).
> > 
> > But this is just me stating what I think would be the logical implementation.
> 
> As I commented already, I think we should *not* allow for atomic write on ZBC in
> scsi_debug. The reason is that as discussed here, implementation of the combined
> features is not as simple as it seems, and since there are no SMR drives out
> there supporting atomic writes, I do not want to give users false hopes with
> scsi debug :)
> 
> Let's make atomic writes and ZBC emulation mutually exclusive.

Sure, I will do that, with your Suggested-by tag.


I do want to note that, for the absolutely most common case, HM-SMR where
logical block size == physical block size, I don't see a problem of these
features being combined.

The drive vendor just needs to set the atomic alignment to something that
makes sense (e.g. equal to the physical block size) with regards to ZBC.


Kind regards,
Niklas

Re: [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

[Damien Le Moal]

On 2026/09/18 12:37, Niklas Cassel wrote:
> On Fri, Sep 18, 2026 at 09:27:10AM +0700, Damien Le Moal wrote:
>>> The above is true for sequential write required zones.
>>> For SWR zones: The write pointer will always be aligned to the physical block
>>> size. (Regardless if physical block size > logical block size, or PBS == LBS).
>>>
>>> For conventional zones, when physical block size > logical block size:
>>> The write pointer can be aligned to logical block size.
>>> Since for conventional zones, the write is implemented using a read modify
>>> write.
>>>
>>>
>>> Thus for conventional zones, if the WP is aligned to LBS, but not PBS,
>>> I think it would make sense that a WRITE ATOMIC would fail with:
>>>
>>> ""
>>> If the starting LBA of an atomic write command does not meet the requirements
>>> of the ATOMIC ALIGNMENT field (see 6.6.4), then the device server shall
>>> terminate the command with CHECK CONDITION status with the sense key set to
>>> ILLEGAL REQUEST and the additional sense code set to INVALID FIELD IN CDB.
>>> ""
>>>
>>> Considering that a write < physical block size is implemented as a RMW on
>>> conventional zones, so the write cannot be done atomically.
>>>
>>> Yet, a normal (non-atomic) write, at the same WP, would succeed (because it
>>> would do a RMW).
>>>
>>> But this is just me stating what I think would be the logical implementation.
>>
>> As I commented already, I think we should *not* allow for atomic write on ZBC in
>> scsi_debug. The reason is that as discussed here, implementation of the combined
>> features is not as simple as it seems, and since there are no SMR drives out
>> there supporting atomic writes, I do not want to give users false hopes with
>> scsi debug :)
>>
>> Let's make atomic writes and ZBC emulation mutually exclusive.
> 
> Sure, I will do that, with your Suggested-by tag.
> 
> 
> I do want to note that, for the absolutely most common case, HM-SMR where
> logical block size == physical block size, I don't see a problem of these
> features being combined.
> 
> The drive vendor just needs to set the atomic alignment to something that
> makes sense (e.g. equal to the physical block size) with regards to ZBC.

Sure, but it may not be that simple in practice because achieving atomic writes
on HDD is not that simple: even though most modern HDDs do have some form of
atomicity for single sector writes (e.g. on EPO events), even that is not
guaranteed at all. So let's not assume anything that may end up being different
than what a real implementation may do.

> 
> 
> Kind regards,
> Niklas


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

[Christoph Hellwig]

On Fri, Sep 18, 2026 at 01:15:36PM +0700, Damien Le Moal wrote:
> Sure, but it may not be that simple in practice because achieving atomic writes
> on HDD is not that simple: even though most modern HDDs do have some form of
> atomicity for single sector writes (e.g. on EPO events), even that is not
> guaranteed at all. So let's not assume anything that may end up being different
> than what a real implementation may do.

Besides that the whole concept of atomic writes on sequential write
required zones does not make much sense.

Atomic writes are about atomic updates of multiple sectors, but
sequential write required zoned never update existing data.  So the best
they could provide is to guarantee that either all or nothing of a single
command is appended at the write pointer.  It is very hard to find a way
to use this feature, as zoned writes all require metadata updates to
point to the current location, and without this the data won't be
reached.  There are some schemes to optimizes this by doing a zoned write
with a header containing the location as a sort of distributed log (zenfs
in userspace would be the canonical example), but even with that a torn
write would invalidate the recovery of this header.

In other words, there really is no point in supporting atomic writes on
ZBC.  So we should not implement it in scsi_debug, and disable the
feature in sd.  If we ever see real hardware and a real use case we can
reconsider, but I doubt it is going to happen.

Re: [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)

[Niklas Cassel]

Hello Christoph,

On Fri, Sep 18, 2026 at 09:06:41AM +0200, Christoph Hellwig wrote:
> On Fri, Sep 18, 2026 at 01:15:36PM +0700, Damien Le Moal wrote:
> > Sure, but it may not be that simple in practice because achieving atomic writes
> > on HDD is not that simple: even though most modern HDDs do have some form of
> > atomicity for single sector writes (e.g. on EPO events), even that is not
> > guaranteed at all. So let's not assume anything that may end up being different
> > than what a real implementation may do.
> 
> Besides that the whole concept of atomic writes on sequential write
> required zones does not make much sense.
> 
> Atomic writes are about atomic updates of multiple sectors, but
> sequential write required zoned never update existing data.  So the best
> they could provide is to guarantee that either all or nothing of a single
> command is appended at the write pointer.  It is very hard to find a way
> to use this feature, as zoned writes all require metadata updates to
> point to the current location, and without this the data won't be
> reached.  There are some schemes to optimizes this by doing a zoned write
> with a header containing the location as a sort of distributed log (zenfs
> in userspace would be the canonical example), but even with that a torn
> write would invalidate the recovery of this header.
> 
> In other words, there really is no point in supporting atomic writes on
> ZBC.  So we should not implement it in scsi_debug, and disable the
> feature in sd.  If we ever see real hardware and a real use case we can
> reconsider, but I doubt it is going to happen.

I have just sent out a new version of this series, and in this patch:
https://lore.kernel.org/linux-scsi/20260918062910.1709791-14-cassel@kernel.org/

a combination of ZBC and atomic writes is rejected by scsi_debug.


This series does not touch sd.c, so changes to sd.c should be a separate patch.
From you reply, it is obvious that you would be able to write a sd.c patch with
a better motivation than anything that I would attempt to cook up.


Kind regards,
Niklas