On 07/07/2015 10:48 PM, Bart Van Assche wrote: > 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 ? > I did intentionally _not_ store a pointer to the attached LUN in the alua_port_group structure, as this would induce yet another potential race condition when devices are being removed.
But meanwhile I've come up with a simpler patch which handles this rather elegantly (methinks :-), and doesn't require any additional infrastructure. I'll be posting it shortly. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage [email protected] +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
