lkml.org 
[lkml]   [2007]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [dm-devel] Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
Jens Axboe wrote:
> A barrier write will include a flush, but it may also use the FUA bit to
> ensure data is on platter. So the only situation where a fallback from a
> barrier to flush would be valid, is if the device lied and told you it
> could do FUA but it could not and that is the reason why the barrier
> write failed. If that is the case, the block layer should stop using FUA
> and fallback to flush-write-flush. And if it does that, then there's
> never a valid reason to switch from using barrier writes to
> blkdev_issue_flush() since both methods would either both work or both
> fail.

IIRC, the FUA bit only forces THAT request to hit the platter before it
is completed; it does not flush any previous requests still sitting in
the write back queue. Because all io before the barrier must be on the
platter as well, setting the FUA bit on the barrier request means you
don't have to follow it with a flush, but you still have to precede it
with a flush.

> It's not block layer breakage, it's a device issue.

How isn't it block layer breakage? If the device does not support
barriers, isn't it the job of the block layer ( probably the scheduler )
to fall back to flush-write-flush?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-05-25 16:51    [W:0.114 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site