Re: [PATCH 3/3] block: reimplement FLUSH/FUA to support merge

From: Jens Axboe
Date: Tue Jan 25 2011 - 06:39:36 EST

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at