On Tue, May 29, 2007 at 11:25:42AM +0200, Stefan Bader wrote: > 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?
Something like that is needed for some dm targets to support barriers. (We needn't always wait for *all* in-flight I/O.) When faced with -EOPNOTSUP, do all callers fall back to a sync in the places a barrier would have been used, or are there any more sophisticated strategies attempting to optimise code without barriers? > 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? An efficient I/O barrier implementation would not normally involve flushing AFAIK: dm surely wouldn't "cause" a higher layer to assume stronger semantics than are provided. Alasdair -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
