On 07/06/2015 11:18 PM, Hannes Reinecke wrote:
However, to handle the above case correctly we would need to keep
track of the entire multipath topology, to figure out which devices
belong to that relative target port and might need to be updated
(there might be several paths in standby, and we will have sent the
RTPG only for one of them).
Patches for that are not done yet, so I thought the above patch
would be a simple stop-gap measure.
Hello Hannes,
Are you sure that keeping track of the entire multipath topology would
be required to implement what I proposed ? In the patch "scsi_dh_alua:
Use separate alua_port_group structure"
(http://thread.gmane.org/gmane.linux.scsi/101388/focus=101380) I see
that the new scsi_dh_alua code keeps track of the target port group
(TPG) ID and relative target port (RTP) ID. As you know this information
can be queried for each LUN via the Device Identification VPD page. How
about caching the TPG and RTP IDs per LUN such that the scsi_dh_alua
code can figure out which LUNs are associated with which target ports by
iterating over the known LUNs ?
Thanks,
Bart.
--
To unsubscribe from this list: 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
