request based dm-multipath, was Re: [PATCH] softirq: fix memory corruption when freeing tasklet_struct

[Christoph Hellwig <hch@infradead.org>]

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.