[lkml]   [2010]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC v2] ext4: Don't send extra barrier during fsync if there are no dirty pages.
    On Fri, Aug 06, 2010 at 02:04:54PM -0400, Ted Ts'o wrote:
    > On Fri, Aug 06, 2010 at 12:13:56AM -0700, Darrick J. Wong wrote:
    > > Yes, it's a proxy for something else. One of our larger products would like to
    > > use fsync() to flush dirty data out to disk (right now it looks like they use
    > > O_SYNC), but they're concerned that the many threads they use can create an
    > > fsync() storm. So, they wanted to know how to mitigate the effects of those
    > > storms. Not calling fsync() except when they really need to guarantee a disk
    > > write is a good start, but I'd like to get ahead of them to pick off more low
    > > hanging fruit like the barrier coordination and not sending barriers when
    > > there's no dirty data ... before they run into it. :)
    > Do they need a barrier operation, or do they just want to initiate the
    > I/O? One of the reasons I found it hard to believe you would have
    > multiple threads all fsync()'ing the same file is that keeping the the
    > file consistent is very hard to do in such a scenario. Maintaining
    > ACID-level consistency without a single thread which coordinates when
    > commit records gets written is I'm sure theoretically possible, but in
    > practice, I wasn't sure any applications would actually be _written_
    > that way.

    > If the goal is just to make sure I/O is getting initiated, without
    > necessarily waiting for assurance that a specific file write has hit
    > the disk platters, it may be that the Linux-specific
    > sync_file_range(2) system call might be a far more efficient way of
    > achieving those ends. Without more details about what this product is
    > doing, it's hard to say, of course.

    I don't know for sure, though given what I've seen of the app behavior I
    suspect they simply want the disk cache flushed, and don't need the full
    ordering semantics. That said, I do think they want to make sure that data
    actually hits the disk platters.


     \ /
      Last update: 2010-08-09 21:39    [W:0.036 / U:93.360 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site