[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45bc1c01-09c7-4c54-b305-f349d0d0e19b@acm.org>
Date: Wed, 4 Oct 2023 14:00:58 -0700
From: Bart Van Assche <bvanassche@....org>
To: "Martin K. Petersen" <martin.petersen@...cle.com>
Cc: 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
On 10/3/23 20:00, Martin K. Petersen wrote:
>
> Bart,
>
>> also that there are no guarantees that the data written by an atomic
>> write will survive a power failure. See also the difference between
>> the NVMe parameters AWUN and AWUPF.
>
> We only care about *PF. The *N variants were cut from the same cloth as
> TRIM and UNMAP.
Hi Martin,
Has the following approach been considered? RWF_ATOMIC only guarantees
atomicity. Persistence is not guaranteed without fsync() / fdatasync().
I think this would be more friendly towards battery-powered devices
(smartphones). On these devices it can be safe to skip fsync() /
fdatasync() if the battery level is high enough.
Thanks,
Bart.
Powered by blists - more mailing lists