[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFzydDRVqbgTgrEuPE4QuO6PE2eiR_3ULL-u4H0_10Y0Ew@mail.gmail.com>
Date: Mon, 31 Oct 2016 18:30:11 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Dave Chinner <david@...morbit.com>
Cc: Christoph Hellwig <hch@....de>, Al Viro <viro@...iv.linux.org.uk>,
Jan Kara <jack@...e.cz>,
Dmitry Monakhov <dmonakhov@...nvz.org>,
Jeff Moyer <jmoyer@...hat.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
linux-aio@...ck.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/4] fs: remove the never implemented aio_fsync file operation
On Mon, Oct 31, 2016 at 1:25 PM, Dave Chinner <david@...morbit.com> wrote:
>
> You mean like this version I posted a year ago:
>
> https://lkml.org/lkml/2015/10/29/517
I still suspect that if we want to do this, we should strive to expose
all the other syncing flags from sync_file_range() too.
Not everybody wants to do just synchronous syncs. Especially if you're
doing async work, you might well want to have one async operation to
*start* the writeback on a range, then do something else, and then do
one to wait for the sync to actually have succeeded.
Yeah, that's more of a "keep writes streaming" interface than a
fsync() like interface, but I think the two really do fit together.
It's kind of sad how we have this very fragmented interface to
writeback, where some operations take that "data vs metadata", some
operations take a range of bytes, and some operations take that "start
writeback vs wait for it", but nothing does all of the above. They are
really just different faces of the same writeback coin.
Linus
Powered by blists - more mailing lists