[dm-devel] Re: [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
Phillip Susi
psusi at cfl.rr.com
Fri May 25 14:49:39 UTC 2007
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?
More information about the dm-devel
mailing list