Re: Allow read IO during share block breaking in dm-thin

[Joe Thornber <thornber@redhat.com>]

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