[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:08pm -0500,
Christoph Hellwig <hch at lst.de> wrote:

> On Mon, Feb 23, 2015 at 02:50:57PM -0500, Mike Snitzer wrote:
> > - Should request-based DM wire up blk_check_plugged() to allow the block
> >   layer's plugging to more directly influence when blk_start_request()
> >   is called from dm_request_fn?
> > 
> > - Put differently: in addition to checking ->busy should dm_request_fn
> >   also maintain and check plugging state that is influenced by
> >   blk_check_plugged()?
> > 
> > (or is this moot given that the block layer will only call q->request_fn
> > when the queue isn't plugged anyway!?)
> > 
> > Basically the long and short of this is: the block layer isn't helping
> > us like we thought (elevator is effectively useless and/or being
> > circumvented).  And this apparently isn't new.
> > 
> > I'll take a more measured look at all of this while also trying to
> > make sense of switching request-based DM over to using blk-mq.
> 
> 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().  Could be a regression crept in and it
went unnoticed until now.  Not sure.

Happy to entertain your question once this immediate issue is under
control (or at least understood).  But it is obviously a worthy
discussion for LSF.