scsi_debug and mutipath, was Re: [PATCH 1/1] block: rework flush sequencing for blk-mq
On Fri, Mar 14, 2014 at 10:13:01AM -0400, Mike Snitzer wrote: > I was more reacting to the assertion you made like multipath regresses > all the time. I'm not faulting you at all for not having tested > multipath. Hell, I even forget to test multipath more than I should. > /me says with shame And I didn't assert that, I just asserted that it gets little testing. > Yeah, not sure why single path scsi_debug "just works", maybe it is a > "feature" of the older multipathd I have kicking around?, but for basic > data path testing scsi_debug is a quick means to an end. I can look > closer at _why_ it gets multipathd in a bit. But maybe Ben or Hannes > will have quicker insight? > > For me, if multipathd is running, if I issue the following a multipath > device gets layered ontop of the associated scsi_debug created sd > device: modprobe scsi_debug dev_size_mb=1024 > > I think it useful to have scsi_debug work with multipath. I know people > in Red Hat's QE organization have even simulated multiple paths with > it.. but I don't recall if they had to hack scsi_debug to do that. I'll > try to find out. Looks like it really shouldn't attach as-is. But scsi_debug should be easily extendable to export two LUNs for the same backing store to help multipath testing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
scsi_debug and mutipath, was Re: [PATCH 1/1] block: rework flush sequencing for blk-mq
On Fri, Mar 14, 2014 at 10:13:01AM -0400, Mike Snitzer wrote: I was more reacting to the assertion you made like multipath regresses all the time. I'm not faulting you at all for not having tested multipath. Hell, I even forget to test multipath more than I should. /me says with shame And I didn't assert that, I just asserted that it gets little testing. Yeah, not sure why single path scsi_debug just works, maybe it is a feature of the older multipathd I have kicking around?, but for basic data path testing scsi_debug is a quick means to an end. I can look closer at _why_ it gets multipathd in a bit. But maybe Ben or Hannes will have quicker insight? For me, if multipathd is running, if I issue the following a multipath device gets layered ontop of the associated scsi_debug created sd device: modprobe scsi_debug dev_size_mb=1024 I think it useful to have scsi_debug work with multipath. I know people in Red Hat's QE organization have even simulated multiple paths with it.. but I don't recall if they had to hack scsi_debug to do that. I'll try to find out. Looks like it really shouldn't attach as-is. But scsi_debug should be easily extendable to export two LUNs for the same backing store to help multipath testing. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
