Am Fr 21.07.2006 13:20 schrieb Mike Christie <michaelc@xxxxxxxxxxx>:
> 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'
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
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
