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!
