Linux SCSI subsystem development
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: John Garry <john.garry@linux.dev>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	"Martin K. Petersen" <mkp@kernel.org>,
	linux-scsi@vger.kernel.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 2/2] scsi: scsi_debug: Validate zone access for WRITE ATOMIC (16)
Date: Fri, 18 Sep 2026 07:37:09 +0200	[thread overview]
Message-ID: <aqzOBedKG6JPbn3C@ryzen> (raw)
In-Reply-To: <d4640976-7cfe-4d29-8a3f-cfb91b474110@kernel.org>

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

  reply	other threads:[~2026-09-18  5:37 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
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 [this message]
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=aqzOBedKG6JPbn3C@ryzen \
    --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