Re: [rfc] fsync_range?

[Nick Piggin <npiggin@suse.de>]

On Tue, Jan 20, 2009 at 01:25:59PM -0800, Bryan Henderson wrote:
> > For database writes, you typically write a bunch of stuff in various
> > regions of a big file (or multiple files), then ideally fdatasync
> > some/all of the written ranges - with writes committed to disk in the
> > best order determined by the OS and I/O scheduler.
> > 
> > For this, taking a vector of multiple ranges would be nice.
> > Alternatively, issuing parallel fsync_range calls from multiple
> > threads would approximate the same thing - if (big if) they aren't
> > serialised by the kernel.
> 
> That sounds like a job for fadvise().  A new FADV_WILLSYNC says you're 
> planning to sync that data soon.  The kernel responds by scheduling the 
> I/O immediately.  fsync_range() takes a single range and in this case is 
> just a wait.  I think it would be easier for the user as well as more 
> flexible for the kernel than a multi-range fsync_range() or multiple 
> threads.

A problem is that the kernel will not always be able to schedule the
IO without blocking (various mutexes or block device queues full etc).
And it takes multiple system calls.

If this is an important functionality, I think we could do an fsyncv.

Having an FADV_ for asynchronous writeout wouldn't hurt either.
POSIX_FADV_DONTNEED basically does that except it also drops the
cache afterwards, wheras FADV_WONTDIRTY or something doesn't
necessarily want that. It would be easy to add one to DTRT.
(and I notice FADV_DONTNEED is not taking notice of the given
range when starting writeout)