From: Niklas Cassel <cassel@kernel.org>
To: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
"Martin K. Petersen" <mkp@kernel.org>
Cc: linux-scsi@vger.kernel.org, Damien Le Moal <dlemoal@kernel.org>,
John Garry <john.garry@linux.dev>,
Niklas Cassel <cassel@kernel.org>
Subject: [PATCH v4 07/10] scsi: scsi_debug: Do not write a partial physical block to a zoned device
Date: Fri, 18 Sep 2026 08:29:18 +0200 [thread overview]
Message-ID: <20260918062910.1709791-19-cassel@kernel.org> (raw)
In-Reply-To: <20260918062910.1709791-12-cassel@kernel.org>
do_device_access() copies one logical block at a time and stops at the
first short copy, so when the data-out buffer is smaller than the
transfer length of the command it can write part of a physical block.
An initiator can arrange that with SG_IO.
A write that does not end on a physical block boundary is perfectly
acceptable to a device that is not zoned, and to a conventional zone,
where the device reads, modifies and writes the physical block that the
write falls in. ZBC-3 r06 (T10/BSR INCITS 579), 4.5.3.3.2, does require
a write to a sequential write required zone to end on a physical block
boundary, though, so a partly written physical block is not a state that
such a zone can be left in.
Stop at the last whole physical block that the buffer holds, for a
sequential write required zone only. The bytes that are left over are
not written, and are reported to the initiator as part of the residual.
With the default physblk_exp=0 the physical block size equals the
logical block size and this changes nothing. Nothing changes either when
the buffer holds all of the data that the command asks for, so a command
that transfers fewer logical blocks than a physical block is unaffected
wherever it is legal.
Assisted-by: LLM
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
issuing a sixteen logical block WRITE(16) through SG_IO with a buffer of
twelve blocks. To a sequential write required zone it now transfers
eight blocks, one whole physical block, and reports the remaining 2048
bytes as the residual; before this patch it transferred twelve. To a
conventional zone it still transfers all twelve and reports no residual.
With physblk_exp=0 an eight block write with a buffer of one block still
transfers one block, wherever it is addressed.
---
drivers/scsi/scsi_debug.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index a4db282ac971..837077a4e740 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -4273,6 +4273,8 @@ static int do_device_access(struct sdeb_store_info *sip, struct scsi_cmnd *scp,
u64 block;
enum dma_data_direction dir;
struct scsi_data_buffer *sdb = &scp->sdb;
+ struct scsi_device *sdp = scp->device;
+ struct sdebug_dev_info *devip = (struct sdebug_dev_info *)sdp->hostdata;
u8 *fsp;
int i, total = 0;
@@ -4300,6 +4302,24 @@ static int do_device_access(struct sdeb_store_info *sip, struct scsi_cmnd *scp,
fsp = sip->storep;
+ /*
+ * A write to a sequential write required zone has to end on a physical
+ * block boundary, so if the data-out buffer does not hold all of the
+ * data that the command asks for, write up to the last whole physical
+ * block that it does hold. What is left over is reported as part of
+ * the residual.
+ */
+ if (do_write && sdebug_dev_is_zoned(devip)) {
+ struct sdeb_zone_state *zsp = zbc_zone(devip, lba);
+
+ if (zsp->z_type == ZBC_ZTYPE_SWR) {
+ u32 avail = (sdb->length - sg_skip) / sdebug_sector_size;
+
+ if (avail < num)
+ num = round_down(avail, 1U << sdebug_physblk_exp);
+ }
+ }
+
block = do_div(lba, sdebug_store_sectors);
/* Only allow 1x atomic write or multiple non-atomic writes at any given time */
--
2.55.0
next prev parent reply other threads:[~2026-09-18 6:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 6:29 [PATCH v4 00/10] scsi: scsi_debug: fix zoned write validation Niklas Cassel
2026-09-18 6:29 ` [PATCH v4 01/10] scsi: scsi_debug: Refuse a zoned device with a non-zero lowest aligned LBA Niklas Cassel
2026-09-18 9:26 ` Damien Le Moal
2026-09-18 6:29 ` [PATCH v4 02/10] scsi: scsi_debug: Make atomic writes and ZBC emulation mutually exclusive Niklas Cassel
2026-09-18 7:21 ` John Garry
2026-09-18 9:26 ` Damien Le Moal
2026-09-18 6:29 ` [PATCH v4 03/10] scsi: scsi_debug: Take the zone metadata lock before the data lock Niklas Cassel
2026-09-18 9:28 ` Damien Le Moal
2026-09-18 6:29 ` [PATCH v4 04/10] scsi: scsi_debug: Evaluate scsi_debug_lbp() only once Niklas Cassel
2026-09-18 9:29 ` Damien Le Moal
2026-09-18 6:29 ` [PATCH v4 05/10] scsi: scsi_debug: Report the residual of a write Niklas Cassel
2026-09-18 6:29 ` [PATCH v4 06/10] scsi: scsi_debug: Enforce physical block alignment of zoned writes Niklas Cassel
2026-09-18 6:29 ` Niklas Cassel [this message]
2026-09-18 9:31 ` [PATCH v4 07/10] scsi: scsi_debug: Do not write a partial physical block to a zoned device Damien Le Moal
2026-09-18 10:25 ` Niklas Cassel
2026-09-18 6:29 ` [PATCH v4 08/10] scsi: scsi_debug: Advance the write pointer over the data written Niklas Cassel
2026-09-18 6:29 ` [PATCH v4 09/10] scsi: scsi_debug: Map the region written by WRITE ATOMIC (16) Niklas Cassel
2026-09-18 7:29 ` John Garry
2026-09-18 8:09 ` Niklas Cassel
2026-09-18 6:29 ` [PATCH v4 10/10] scsi: scsi_debug: Validate the access parameters of " Niklas Cassel
2026-09-18 7:33 ` John Garry
2026-09-18 7:53 ` Niklas Cassel
2026-09-18 8:19 ` John Garry
2026-09-18 8:55 ` Niklas Cassel
2026-09-18 9:32 ` Damien Le Moal
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=20260918062910.1709791-19-cassel@kernel.org \
--to=cassel@kernel.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=dlemoal@kernel.org \
--cc=john.garry@linux.dev \
--cc=linux-scsi@vger.kernel.org \
--cc=mkp@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