[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <FBAE8433-865B-4D4D-B658-27E234FE829F@fb.com>
Date: Tue, 9 Apr 2019 18:56:56 +0000
From: Chris Mason <clm@...com>
To: Jens Axboe <axboe@...nel.dk>
CC: Christoph Hellwig <hch@...radead.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] io_uring: add support for barrier fsync
On 9 Apr 2019, at 14:46, Jens Axboe wrote:
> On 4/9/19 12:42 PM, Chris Mason wrote:
>> Looking at the patch, why is fsync special? Seems like you could add
>> this ordering bit to any write?
>
> It's really not, the exact same technique could be used on any type of
> command to imply ordering. My initial idea was to have an explicit
> barrier/ordering command, but I didn't think that separating it from
> an
> actual command would be needed/useful.
Might want to order discards? Commit a transaction to free some blocks,
discard those blocks?
>
>> While you're here, do you want to add a way to FUA/cache flush?
>> Basically the rest of what user land would need to make their own
>> write-back-cache-safe implementation.
>
> FUA would be a WRITEV/WRITE_FIXED flag, that should be trivially
> doable.
>
> In terms of cache flush, that's very heavy handed (and storage
> oriented). What applications would want/need to do an explicit whole
> device flush?
Basically if someone is writing a userland filesystem they'd want to
cache flush for the same reasons the kernel filesystems do.
-chris
Powered by blists - more mailing lists