[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <yq1h6n7rume.fsf@ca-mkp.ca.oracle.com>
Date: Tue, 03 Oct 2023 22:53:20 -0400
From: "Martin K. Petersen" <martin.petersen@...cle.com>
To: Bart Van Assche <bvanassche@....org>
Cc: "Martin K. Petersen" <martin.petersen@...cle.com>,
John Garry <john.g.garry@...cle.com>, axboe@...nel.dk,
kbusch@...nel.org, hch@....de, sagi@...mberg.me,
jejb@...ux.ibm.com, djwong@...nel.org, viro@...iv.linux.org.uk,
brauner@...nel.org, chandan.babu@...cle.com, dchinner@...hat.com,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-nvme@...ts.infradead.org, linux-xfs@...r.kernel.org,
linux-fsdevel@...r.kernel.org, tytso@....edu, jbongio@...gle.com,
linux-api@...r.kernel.org
Subject: Re: [PATCH 10/21] block: Add fops atomic write support
Bart,
> I'm still wondering whether we really should support storage devices
> that report an ATOMIC TRANSFER LENGTH GRANULARITY that is larger than
> the logical block size.
We should. The common case is that the device reports an ATOMIC TRANSFER
LENGTH GRANULARITY matching the reported physical block size. I.e. a
logical block size of 512 bytes and a physical block size of 4KB. In
that scenario a write of a single logical block would require
read-modify-write of a physical block.
> Is my understanding correct that the NVMe specification makes it
> mandatory to support single logical block atomic writes since the
> smallest value that can be reported as the AWUN parameter is one
> logical block because this parameter is a 0's based value? Is my
> understanding correct that SCSI devices that report an ATOMIC TRANSFER
> LENGTH GRANULARITY that is larger than the logical block size are not
> able to support the NVMe protocol?
That's correct. There are obviously things you can express in SCSI that
you can't in NVMe. And the other way around. Our intent is to support
both protocols.
--
Martin K. Petersen Oracle Linux Engineering
Powered by blists - more mailing lists