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
tables.
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
