2007/5/28, Alasdair G Kergon <agk@xxxxxxxxxx>:
On Mon, May 28, 2007 at 11:30:32AM +1000, Neil Brown wrote: > 1/ A BIO_RW_BARRIER request should never fail with -EOPNOTSUP. The device-mapper position has always been that we require > a zero-length BIO_RW_BARRIER (i.e. containing no data to read or write - or emulated, possibly device-specific) before we can provide full barrier support. (Consider multiple active paths - each must see barrier.)
Couldn't the same be ac hived by doing a sort of suspend, issuing the barrier request, calling flush to all mapped devices and then wait for in-flight I/O to go to zero? This certainly has the aspect of performance degradation (but that seem to be a generic problem with barriers not being specific enough).
Until every device supports barriers -EOPNOTSUP support is required. (Consider reconfiguration of stacks of devices - barrier support is a dynamic block device property that can switch between available and unavailable at any time.)
Is only an issue if not doing barrier handling in dm. In that case the support in the devices is helpful but not required. For something else: Alasdair, I am not a hundred percent sure about that but I think that just passing the barrier flag on to mapped devices might in some (maybe they are rare) cases cause a layer above to think all data is on-disk while this isn't necessarily true (see my previous post). What do you think? Stefan - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
