On Fri, Jan 26, 2024 at 07:56:39AM +0100, Hannes Reinecke wrote: > DM-multipath schedules based on request (if you use the request-based > interface) or bios (if you use the bio-based interface). > Any merge decision is typically done by the block layer when combining bios > into requests; and you can only merge bios if the bvecs are adjacent. > So if you use bio-based multipathing you will spread sequential bios > across all paths, leaving the block layer unable to merge requests. While I think the current code would do that, there is nothing inherent in the interface forcing it to do that. The blk_plug allows drivers to attach callbacks to batch up plugged bios, and the md raid code makes use of that to get larger I/O, which is rather essential for partity RAID. > Another thing is timeouts; bios don't do timeouts, so a bio can run > for an arbitrary time with no chance of interrupting it. > Requests do have a timeout, and will be aborted from the driver when > the timeout is hit. > Seeing that 99% of all I/O issues I've seen _are_ timeouts it becomes > a crucial feature if you want dm-multipath to control failover time. This does not matter - a timeout bio will return an error to the submitter even on a request based driver unless the timeout handler fixed it up. And there is nothing preventing a bio based driver from having it's own timeout. We had quite a few in the past. But dm-rq doesn't even set a timeout, so for the current situation this is 100% irrelevant. So while I'm not sure if using the existing bio based mpath code with plugging would be enough to suite all users of dm-multipath, I'd really love to see someone actually trying it. Removing the request based path would significantly simplify dm, and also remove a fair amount of hacks from the block layer.
