Re: [rfc] fsync_range?

[Nick Piggin <npiggin@suse.de>]

On Wed, Jan 21, 2009 at 04:59:21AM +0000, Jamie Lokier wrote:
> Nick Piggin wrote:
> > This is just another reason why I prefer to just try to evolve the
> > traditional fsync interface slowly.
> 
> But sync_file_range() has a bug, which you've pointed out - the
> missing _data-retrieval_ metadata isn't synced.  In other words, it's
> completely useless.

I don't know. I don't think this is a newly discovered problem.
I think it's been known for a while, so I don't know what's
going on.
 

> If that bug isn't going to be fixed, delete sync_file_range()
> altogether.  There's no point keeping it if it's broken.  And if it's
> fixed, it'll do what your fsync_range() does, so why have both?

Well the thing is it doesn't. Again it comes back to the whole
writeout thing, which makes it more constraining on the kernel to
optimise.

For example, my fsync "livelock" avoidance patches did the following:

1. find all pages which are dirty or under writeout first.
2. write out the dirty pages.
3. wait for our set of pages.

Simple, obvious, and the kernel can optimise this well because the
userspace has asked for a high level request "make this data safe"
rather than low level directives. We can't do this same nice simple
sequence with sync_file_range because SYNC_FILE_RANGE_WAIT_AFTER
means we have to wait for all writeout pages in the range, including
unrelated ones, after the dirty writeout. SYNC_FILE_RANGE_WAIT_BEFORE
means we have to wait for clean writeout pages before we even start
doing real work.