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 v5 07/10] scsi: scsi_debug: Do not write a partial physical block to a zoned device
Date: Mon, 21 Sep 2026 17:40:23 +0200 [thread overview]
Message-ID: <20260921154015.2971990-19-cassel@kernel.org> (raw)
In-Reply-To: <20260921154015.2971990-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
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
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.
---
Changes since v4: the division is a bit shift now, as suggested.
drivers/scsi/scsi_debug.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index a4db282ac971..cf5037e81952 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,25 @@ 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)
+ >> ilog2(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-21 15:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 15:40 [PATCH v5 00/10] scsi: scsi_debug: fix zoned write validation Niklas Cassel
2026-09-21 15:40 ` [PATCH v5 01/10] scsi: scsi_debug: Refuse a zoned device with a non-zero lowest aligned LBA Niklas Cassel
2026-09-21 15:40 ` [PATCH v5 02/10] scsi: scsi_debug: Make atomic writes and ZBC emulation mutually exclusive Niklas Cassel
2026-09-21 15:40 ` [PATCH v5 03/10] scsi: scsi_debug: Take the zone metadata lock before the data lock Niklas Cassel
2026-09-21 15:40 ` [PATCH v5 04/10] scsi: scsi_debug: Evaluate scsi_debug_lbp() only once Niklas Cassel
2026-09-21 15:53 ` John Garry
2026-09-23 9:54 ` Johannes Thumshirn
2026-09-21 15:40 ` [PATCH v5 05/10] scsi: scsi_debug: Report the residual of a write Niklas Cassel
2026-09-21 15:40 ` [PATCH v5 06/10] scsi: scsi_debug: Enforce physical block alignment of zoned writes Niklas Cassel
2026-09-21 15:40 ` Niklas Cassel [this message]
2026-09-21 15:40 ` [PATCH v5 08/10] scsi: scsi_debug: Advance the write pointer over the data written Niklas Cassel
2026-09-21 15:40 ` [PATCH v5 09/10] scsi: scsi_debug: Map the region written by WRITE ATOMIC (16) Niklas Cassel
2026-09-21 15:50 ` John Garry
2026-09-24 11:10 ` Niklas Cassel
2026-09-25 9:32 ` John Garry
2026-09-21 15:40 ` [PATCH v5 10/10] scsi: scsi_debug: Validate the access parameters of " Niklas Cassel
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=20260921154015.2971990-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