[dm-devel] dm-mpath request merging concerns [was: Re: It's time to put together the schedule]

[Mike Snitzer]

On Mon, Feb 23 2015 at  3:39pm -0500,
Mike Snitzer <snitzer at redhat.com> wrote:

> On Mon, Feb 23 2015 at  3:08pm -0500,
> Christoph Hellwig <hch at lst.de> 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.