On 3/10/26 16:52, John Garry wrote:
On 10/03/2026 13:23, Hannes Reinecke wrote:
sdev->scsi_mpath_dev->index = ida_alloc(&scsi_mpath_head->ida,
GFP_KERNEL);
if (sdev->scsi_mpath_dev->index < 0) {
ret = sdev->scsi_mpath_dev->index;
diff --git a/include/scsi/scsi_multipath.h b/include/scsi/
scsi_multipath.h
index 2011447f482d6..7c7ee2fb7def7 100644
--- a/include/scsi/scsi_multipath.h
+++ b/include/scsi/scsi_multipath.h
@@ -38,6 +38,9 @@ struct scsi_mpath_device {
int index;
atomic_t nr_active;
struct scsi_mpath_head *scsi_mpath_head;
+ int alua_state;
+ int alua_pref;
+ int alua_valid_states;
char device_id_str[SCSI_MPATH_DEVICE_ID_LEN];
};
Is there a specific reason why this cannot be in the generic code?
Sure, it's possible....
After all, if the device reports anything else than ALUA_STATE_OPTIMAL
or ALUA_STATE_ACTIVE I/O will fail, irrespective of multipath being
active.
I would love to see that in the generic SCSI code, independent on this
patchset. It would allow us to simplify the device handler code, too,
as then device handler really would only be required for explicit
ALUA. (And could be ignored for scsi-multipathing).
Right, so you would like to see alua_port_group management in a core
ALUA driver as well, right?
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.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
[email protected] +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
