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