lkml.org 
[lkml]   [2014]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectscsi_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.


\
 
 \ /
  Last update: 2014-03-15 14:41    [W:0.113 / U:0.676 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site