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

[Hannes Reinecke <hare@suse.de>]

On 06/05/2014 03:36 PM, Christoph Hellwig wrote:
> 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.
>
Ok, might be.

It just seemed the obvious thing to do. But if there are arguments
against it one should rework that bit.

> 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..
>
And which was precisely why I haven't continued with this patchset, too.
The primary reason for cloning the bios would from my POV would be 
so that we can handle partial completion properly. When eliminating 
it we would be always return an error here.
But then one does wonder whether a partial completion shouldn't be 
considered an error anyway.
I've never felt comfortable with that bit in the stack, and tried to 
shirk it as much as possible.

Maybe Mike C. has some ideas here; I seem to remember he once worked 
on that code ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)