From: Niklas Cassel <cassel@kernel.org>
To: John Garry <john.garry@linux.dev>
Cc: "James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
"Martin K. Petersen" <mkp@kernel.org>,
linux-scsi@vger.kernel.org, Damien Le Moal <dlemoal@kernel.org>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)
Date: Thu, 17 Sep 2026 18:10:11 +0200 [thread overview]
Message-ID: <3709D24B-4D27-44CC-92C5-59DC66309931@kernel.org> (raw)
In-Reply-To: <35ad0b9c-06bb-4ccd-8e58-fde4d859b85e@linux.dev>
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
next prev parent reply other threads:[~2026-09-17 16:10 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 8:45 [PATCH 0/2] scsi: scsi_debug: fix zoned write validation Niklas Cassel
2026-09-17 8:45 ` [PATCH 1/2] scsi: scsi_debug: Enforce physical block alignment of zoned writes Niklas Cassel
2026-09-17 9:05 ` Damien Le Moal
2026-09-17 10:42 ` Niklas Cassel
2026-09-17 8:45 ` [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16) Niklas Cassel
2026-09-17 9:00 ` sashiko-bot
2026-09-17 9:09 ` Niklas Cassel
2026-09-17 9:07 ` Damien Le Moal
2026-09-17 9:38 ` John Garry
2026-09-17 9:56 ` Niklas Cassel
2026-09-17 10:26 ` John Garry
2026-09-17 10:35 ` Niklas Cassel
2026-09-17 15:42 ` John Garry
2026-09-17 16:10 ` Niklas Cassel [this message]
2026-09-17 16:40 ` John Garry
2026-09-17 17:37 ` Niklas Cassel
2026-09-18 2:27 ` Damien Le Moal
2026-09-18 5:37 ` Niklas Cassel
2026-09-18 6:15 ` Damien Le Moal
2026-09-18 7:06 ` Christoph Hellwig
2026-09-18 7:27 ` 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=3709D24B-4D27-44CC-92C5-59DC66309931@kernel.org \
--to=cassel@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=dlemoal@kernel.org \
--cc=hch@lst.de \
--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