Re: [PATCHv2] sd: retry READ CAPACITY for ALUA state transition

[Hannes Reinecke <hare@suse.de>]

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
hare@suse.de			               +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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html