Re: [RFC PATCH 0/7] dm-mpath: Do not clone requests

[Christoph Hellwig <hch@infradead.org>]

Oh, you're not even cloning the request.  I though you'd just avoid
cloning the bios.  Passing the requests through isn't going to work
when sitting on top of a blk-mq driver.

I have a queue I'm trying to start to test now that approaches this
a little bit differently:

 - request based dm is converted to use blk-mq itself, allowing us to
   allocate private data as part of the incoming request, and gets
   rid of the nasty prep_fn/request_fn split
 - it then just allocates a new request on the underlying device after
   chosing the path.  By using blk_get_request to allocate the lower
   request dm-mpath doesn't care if the underlying device uses blk-mq
   or not.

As said I'm already running into issues with plain dm mpath in my
trivial test setup, so this is stalled for the moment.

But I'd still love to understand why dm even bothers cloning the bios.
At the request layer we only touch the bios in two places: first
for merging in into the request, and second in blk_update_request.

Now with dm-mpath we'd never want to do this sort of merging for the
lower request anyway, and I don't see a real problem keeting the lower
driver complete the bio and just never call blk_update_request in
dm-mpath either.  At least that's my impression that hasn't made contact
with the ugly reality yet..