[PATCH 5/8] scsi: scsi-multipath: Add basic ALUA support
John Garry
john.g.garry at oracle.com
Tue Mar 10 11:13:42 PDT 2026
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!
More information about the Linux-nvme
mailing list