Hi Dennis, On Fri, Aug 23, 2013 at 10:35:30AM +0800, Teng-Feng Yang wrote: > So here is my question, do we really need to quiesce all share read > IOs before adding a new data mapping, or the share read IO's deferred > set is meant to deal with some other problems? This is a good question. As you say we could let the read ios continue to run to the old block. For large block sizes this could reduce latency of those reads. I have a suspicion that I originally wrote things this way so we never complete a read bio with older data after earlier completing a write bio. But if the bios were submitted concurrently there's no need to observe this restriction. There is one thing you need to consider if you're going to make this change. The old block may well have it's reference count reduced to zero as a result of inserting the new mapping. This in itself is fine; we're careful to never free and realloc a block within the same transaction. But it does mean you'd need to start quiescing as part of the commit operation. I worry that introducing quiescing at the commit level would impact the latency of ios to all blocks, rather than just the one that's having it's sharing broken. You could restructure the REQ_FUA/REQ_FLUSH code (which triggers the commits), such that only they get stalled waiting for the quiesce, but that's a chunk more work. Do some benchmarking, quantify the problem. Then we can make a call on whether the development effort is worth it. - Joe -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
