[dm-devel] RE: [PATCH RFC] move scsi parts of dm hw handlers to scsi layer

[Edward Goggin]

> -----Original Message-----
> From: linux-scsi-owner at vger.kernel.org 
> [mailto:linux-scsi-owner at vger.kernel.org] On Behalf Of Hannes Reinecke
> Sent: Friday, July 21, 2006 7:41 AM
> To: Mike Christie
> Cc: dm-devel at redhat.com; linux-scsi at vger.kernel.org; agk at redhat.com
> Subject: Re: [PATCH RFC] move scsi parts of dm hw handlers to 
> scsi layer
> 
> Am Fr 21.07.2006 13:20 schrieb Mike Christie <michaelc at cs.wisc.edu>:
> 
> > Currently dm-multipath has what it calls hw_handlers that contain hw
> > details and currently those handlers can be used to failover storage
> > works, LSI/Engenio RDAC mode, and EMC Clariion boxes. This code is a
> > little strange in dm-multipath and they are doing scsi no 
> good (think
> > about problems initializing scsi disks/paths when they are in a
> > passive
> > path that requires explicit/manual activation and we retry over and
> > over
> > and over).
> > 
> Yes, good idea. And it would even solve the problem of 
> getting all this
> weird
> error messages during booting as now these handlers are 
> independently of
> of
> the multipathing configuration and we're now able to handle 
> weird path 
> configurations natively.
> 
> > The patch below begins to push the scsi hw handler code down to the
> > scsi
> > layer. I only began to covert dm-emc.c and it only hooks in at the
> > sense
> > decoding in scsi_error.c. I wanted to make sure I was going 
> about the
> > module loading and binding correctly. With a new target bus we could
> > do
> > some driver model stuff instead, but I was not sure if that was
> > appropriate for this?
> > 
> Why don't we use scsi_devinfo for this?
> We have to have some sort of device table anyway as these handlers are
> far from being generic, so any sense code which triggers action on one
> device might be perfectly ok for others.
> 
> Easiest way would be to have one BLIST flag for each hardware handler
> and merge the respective hardware handler into that target if the
> blacklist entry matches.
> 
> > Next up would be to get Jens's cmd type tree and work on the message
> > passing code.
> > 
> > And this patch currently does not work since I do not have 
> a Clariion
> > box and I do not know what to match for the {vendor, model} tuple. I
> > think it was something like DCG or DGC and the model had different
> > RAID
> > strings depending on how it was setup and could have some 
> other string
> > if it did not use RAID. If you have a Clariion or you work 
> for EMC and
> > happen to know this info could you pass those strings to me?
> > 
> IIRC this is
> 
> 'DGC' 'DISK'
> 'DGC' 'RAID 10'
> 'DGC' 'RAID 5'

And 'DGC' 'LUNZ'

What about supporting a wildcard model string?

> 
> Hrmph. There is one bit which doesn't quite work out.
> While the hardware handler knows how to handle error codes and how to
> switch
> paths for a specific device, it doesn't know _when_ to switch it.
> I don't think it's a clever idea to switch paths whenever you 
> encounter
> an
> passive path. Seems like you could do a nice ping-pong that way ...
> 
> Cheers,
> 
> Hannes
> 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-scsi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>