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@xxxxxxx +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)
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
