[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <yq1o7heqmk0.fsf@ca-mkp.ca.oracle.com>
Date: Wed, 04 Oct 2023 14:26:42 -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,
Himanshu Madhani <himanshu.madhani@...cle.com>
Subject: Re: [PATCH 01/21] block: Add atomic write operations to
request_queue limits
Bart,
> In my opinion there is a contradiction between the above reply and
> patch 19/21 of this series. Data written with the SCSI WRITE ATOMIC
> command is not guaranteed to survive a power failure.
That is not the intent. The intent is to ensure that for any given
application block (say 16KB), the application block on media will
contain either 100% old data or 100% new data. Always.
If a storage device offers no such guarantee across a power failure,
then it is not suitable for use by applications which do not tolerate
torn writes. That is why the writes-are-atomic-unless-there's-a-problem
variant of the values reports in NVMe are of no interest.
--
Martin K. Petersen Oracle Linux Engineering
Powered by blists - more mailing lists