On Mon, Feb 23 2015 at 3:39pm -0500, Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > On Mon, Feb 23 2015 at 3:08pm -0500, > Christoph Hellwig <hch@xxxxxx> wrote: > > > > I'd like to rephrase the question a little bit: Is the request layer + > > device mapper really the right combination for driving multipath I/O? > > > > If we were moving it to a set of helpers where blk-mq drivers could > > just ask for resubmitting I/O on another device of it's choice we > > would be able to cut the middle man with all the problems that having > > a middle man entails. That is all the busy checks that need to be > > propagated, the plugging question, the various merge parameters that need > > to be communicated from the driver, the sense code intepretation for which > > dm needs to call back into SCSI (or NVMe for that matter). To me > > it seems like a much better idea to let the driver (*) driver the > > decision, with a few library helpers provided to deal with queue selection > > algorithms and other faіrly generic pieces of code. > > > > (*) that is block layer driver, in case of SCSI it would still be the > > midlayer pulling the strings. > > OK, fair question. But making existing DM-multipath work as expected > (effective consumer of old block's elevators) would be a nice thing to > do before blowing it up with a redesign. > > There is a lot of block code that is only used by request-based DM, the > big one being blk_queue_bio(). And yet I'm wrong, blk_queue_bio() is clearly used as the primary make_request function. Which is good, arrests my fears that DM was only consumer. DM is the only consumer of symbol export. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
