On Thu, Jan 12 2017 at 3:00am -0500, Christoph Hellwig <hch@xxxxxx> wrote: > On Wed, Jan 11, 2017 at 08:09:37PM -0500, Mike Snitzer wrote: > > I'm not following your reasoning. > > > > dm_blk_ioctl calls __blkdev_driver_ioctl and will call scsi_cmd_ioctl > > (sd_ioctl -> scsi_cmd_blk_ioctl -> scsi_cmd_ioctl) if DM's underlying > > block device is a scsi device. > > Yes, it it does. But scsi_cmd_ioctl as called from sd_ioctl will > operate entirely on the SCSI request_queue - dm-mpath will never see > the BLOCK_PC request generated by it. I lost sight of the fact that BLOCK_PC requests are sent down via the normal request submission (and not the ioctl path). So my previous reply wasn't relevant. What is "incomplete" about request-based DM's BLOCK_PC support? This code goes back to when request-based DM multipath was first introduced via commit cec47e3d4a -- but I've never used the BLOCK_PC requests for SCSI pass through myself. I don't know who is using it.. are you aware of some upper layer filesystem or userspace submission path for these BLOCK_PC requests that they'd be passing through DM? I'm also missing how you're saying the new blk-mq request-based DM will work with your new model. I appreciate that we get the request from the underlying blk-mq request_queue and it'll be properly sized. But wouldn't we need to pass data back up for these SCSI pass-through requests? So wouldn't the top-level multipath request_queue need to setup cmd_size? Sorry for the naive questions (that clearly speak to me not understanding how this aspect of the block and SCSI code work).. but I'd like to understand where DM will be lacking going forward. -- 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
