Re: [PATCH 5/8] scsi: scsi-multipath: Add basic ALUA support

[John Garry <john.g.garry@oracle.com>]

On 10/03/2026 17:54, Hannes Reinecke wrote:
>>
>> If yes, to repeat, it is hard to separate the DH stuff out...but I can 
>> try. Examples I would need to deal with (and associated handling):
>>
>> - alua_port_group members like dh_list
>> - alua_dh_data memebers like init_error
>> - everything in alua_queue_data
>>
> While the port group handling looks nice (and there certainly is
> a certain neatness to it), it kinda assumes too much about the
> internal layout of the hierarchy within the target.
> Technically, a target is only required to provide a device
> identifier, and a group id (such that you can match with
> RTPG output). However, you have no idea which of the various
> device IDs are part of the same enclosure; that information
> is not required to be present.
> So you cannot assume that group ID A reported from device X
> is the same group as group ID A reported from device Y.
> The only reliable way is to check with the RTPG output, as
> that contains all device identifiers for the defined group
> IDs.
> But: caching RTPG output is problematic (as it'll change
> whenever a path state change happens), and it'll need to
> contain references to the SCSI devices, introducing all
> sorts of locking issues and race conditions.
> So probably I would not go down that way (at least initially),
> but rather read RTPG during scanning, and set the values
> directly in the scsi device.
> 
> We then need to re-read that information whenever we hit
> a relevant sense code, but arguably we'll need to do that
> anyway.

Hmmm... what you are describing seems to be now more like what I have in 
this series except only I did not have the ALUA info stored in the 
scsi_device struct.

So if I go down these lines, maybe for sense-triggered updates I can 
have something where scsi-multipath.c or scsi_dh_alua.c can trigger the 
RTPG to be issued and this updates scsi_device ALUA info. It sounds 
simple enough, but probably isn't for scsi_dh_alua.c :)

Thanks!