[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZUz98KriiLsM8oQd@casper.infradead.org>
Date: Thu, 9 Nov 2023 15:42:40 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Christoph Hellwig <hch@....de>
Cc: John Garry <john.g.garry@...cle.com>, axboe@...nel.dk,
kbusch@...nel.org, sagi@...mberg.me, jejb@...ux.ibm.com,
martin.petersen@...cle.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, Alan Adamson <alan.adamson@...cle.com>
Subject: Re: [PATCH 21/21] nvme: Support atomic writes
On Thu, Nov 09, 2023 at 04:36:03PM +0100, Christoph Hellwig wrote:
> Also I really want a check in the NVMe I/O path that any request
> with the atomic flag set actually adhers to the limits to at least
> partially paper over the annoying lack of a separate write atomic
> command in nvme.
That wasn't the model we had in mind. In our thinking, it was fine to
send a write that crossed the atomic write limit, but the drive wouldn't
guarantee that it was atomic except at the atomic write boundary.
Eg with an AWUN of 16kB, you could send five 16kB writes, combine them
into a single 80kB write, and if the power failed midway through, the
drive would guarantee that it had written 0, 16kB, 32kB, 48kB, 64kB or
all 80kB. Not necessarily in order; it might have written bytes 16-32kB,
64-80kB and not the other three.
Powered by blists - more mailing lists