Re: [rfc] fsync_range?

[Jamie Lokier <jamie@shareable.org>]

Bryan Henderson wrote:
> Nick Piggin <npiggin@suse.de> wrote on 01/20/2009 05:36:06 PM:
> 
> > On Tue, Jan 20, 2009 at 01:25:59PM -0800, Bryan Henderson wrote:
> > > > 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).
> 
> I don't really see the problem with that.  We're talking about a program 
> that is doing device-synchronous I/O.  Blocking is a way of life.  Plus, 
> the beauty of advice is that if it's hard occasionally, the kernel can 
> just ignore it.

If you have 100 file regions, each one a few pages in size, and you do
100 fsync_range() calls, that results in potentally far from optimal
I/O scheduling (e.g. all over the disk) *and* 100 low-level disk cache
flushes (I/O barriers) instead of just one at the end.  100 head seeks
and 100 cache flush ops can be very expensive.

This is the point of taking a vector of ranges to flush - or some
other way to "plug" the I/O and only wait for it after submitting it
all.

-- Jamie