[lkml]   [2007]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [dm-devel] [RFD] BIO_RW_BARRIER - what it means for devices, filesystems, and dm/md.
Neil Brown wrote:
> There is no guarantee that a device can support BIO_RW_BARRIER - it is
> always possible that a request will fail with EOPNOTSUPP.

Why is it not the job of the block layer to translate for broken devices
and send them a flush/write/flush?

> These devices would find it very hard to support BIO_RW_BARRIER.
> Doing this would require keeping track of all in-flight requests
> (which some, possibly all, of the above don't) and then:

The device mapper keeps track of in flight requests already. When
switching tables it has to hold new requests and wait for in flight
requests to complete before switching to the new table. When it gets a
barrier request it just needs to do the same thing, only not switch

> I think the best approach for this class of devices is to return
> -EOPNOSUP. If the filesystem does the wait (which they all do
> already) and the blkdev_issue_flush (which is easy to add), they
> don't need to support BIO_RW_BARRIER.

Why? The personalities should just pass the BARRIER flag down to each
underlying device, and the dm common code should wait for all in flight
io to complete before sending the barrier to the personality.

> For devices that don't support QUEUE_ORDERED_TAG (i.e. commands sent to
> the controller can be tagged as barriers), SCSI will use the
> SYNCHRONIZE_CACHE command to flush the cache after the barrier
> request (a bit like the filesystem calling blkdev_issue_flush, but at

Don't you have to flush the cache BEFORE the barrier to ensure that
previous IO is committed first, THEN the barrier write?

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

 \ /
  Last update: 2007-05-25 17:13    [W:0.180 / U:10.200 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site