On Fri, Apr 19, 2024 at 10:27:53AM +0200, Martin Wilck wrote: > Well, it's just a matter of setting "queue_mode" in the multipath > configuration. Yes, and no. We'd probably at very last want a blk_plug callback to allow making decisions for entire large I/Os instead of on a per-bio basis. > Mike has pointed out in 76e33fe4e2c4 that many of the original reasons > for introducing request-based dm-multipath have been obsoleted by > faster hardware and improvements in the generic block layer. Yes. > I am open for discussion on this subject, but with my distribution > maintainer hat on, I don't expect the default being changed for end > customers soon. Actually, with NVMe rising, I wonder if a major > technology switch for dm-multipath (which is effectively SCSI multipath > these days) makes sense at this point in time. Well, it'll take ages until anything upstream gets into the enterprise distros, which array users tend to use anyway. But I'd really love to get the ball rolling upstream rather sooner than later even if there is no need for immediate action. The reason is that request based dm multipath causes a lot of special casing in the block core and dm, and that has become a significant maintenance burden. So if you have a chance to test the current bio based path, or help with testing a plug callback (I can try to write a patch for that, but I don't really have a good test setup) we can start to see where we are in practice in terms of still needing the request based stacking, and if there is a feasible path to move away from it.
