[lkml]   [2011]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 3/3] block: reimplement FLUSH/FUA to support merge
    On 2011-01-25 11:21, Tejun Heo wrote:
    > Hello, Darrick.
    > On Mon, Jan 24, 2011 at 12:31:55PM -0800, Darrick J. Wong wrote:
    >>> So, I think it's better to start with something simple and improve it
    >>> with actual testing. If the current simple implementation can match
    >>> Darrick's previous numbers, let's first settle the mechanisms. We can
    >> Yep, the fsync-happy numbers more or less match... at least for 2.6.37:
    > Good to hear. Thanks for the detailed testing.
    >> I'll give 2.6.38-rc2 a try later, though -rc1 didn't boot for me, so these
    >> numbers are based on a backport to .37. :(
    > Well, there hasn' been any change in the area during the merge window
    > anyway, so I think testing on 2.6.37 should be fine.
    >>> I don't really think we should design the whole thing around broken
    >>> devices which incorrectly report writeback cache when it need not.
    >>> The correct place to work around that is during device identification
    >>> not in the flush logic.
    >> elm3a4_sas and elm3c71_extsas advertise writeback cache yet the
    >> flush completion times are suspiciously low. I suppose it could be
    >> useful to disable flushes to squeeze out that last bit of
    >> performance, though I don't know how one goes about querying the
    >> disk array to learn if there's a battery behind the cache. I guess
    >> the current mechanism (admin knob that picks a safe default) is good
    >> enough.
    > Yeap, that or a blacklist of devices which lie.
    > Jens, what do you think? If you don't object, let's put this through
    > linux-next.

    I like the approach, I'll queue it up for 2.6.39.

    Jens Axboe

     \ /
      Last update: 2011-01-25 12:41    [W:0.022 / U:58.056 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site