On Thu, Apr 28 2016 at 11:40am -0400, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 2016-04-28 at 08:11 -0400, Mike Snitzer wrote: > > Full disclosure: I'll be looking at reinstating bio-based DM multipath to > > regain efficiencies that now really matter when issuing IO to extremely > > fast devices (e.g. NVMe). bio cloning is now very cheap (due to > > immutable biovecs), coupled with the emerging multipage biovec work that > > will help construct larger bios, so I think it is worth pursuing to at > > least keep our options open. Please see the 4 topmost commits I've published here: https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/log/?h=dm-4.8 All request-based DM multipath support/advances have been completly preserved. I've just made it so that we can now have bio-based DM multipath too. All of the various modes have been tested using mptest: https://github.com/snitm/mptest > OK, but remember the reason we moved from bio to request was partly to > be nearer to the device but also because at that time requests were > accumulations of bios which had to be broken out, go back up the stack > individually and be re-elevated, which adds to the inefficiency. In > theory the bio splitting work will mean that we only have one or two > split bios per request (because they were constructed from a split up > huge bio), but when we send them back to the top to be reconstructed as > requests there's no guarantee that the split will be correct a second > time around and we might end up resplitting the already split bios. If > you do reassembly into the huge bio again before resend down the next > queue, that's starting to look like quite a lot of work as well. I've not even delved into the level you're laser-focused on here. But I'm struggling to grasp why multipath is any different than any other bio-based device... FYI, the paper I reference in my "dm mpath: reinstate bio-based support" commit gets into what I've always thought the real justification was for the transition from bio-based to request-based. -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
