Now that ALUA is supported, we can maintain sdev->access_state.

However, preferred_path is still not maintained as that that is related
to transitioning  state and we do not yet support that (for SCSI
multipath).

Signed-off-by: John Garry <john.g.garry@oracle.com>
---
 drivers/scsi/scsi_multipath.c | 1 +
 drivers/scsi/scsi_sysfs.c     | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_multipath.c b/drivers/scsi/scsi_multipath.c
index 0a314080bf0a5..0c34b1151f5bf 100644
--- a/drivers/scsi/scsi_multipath.c
+++ b/drivers/scsi/scsi_multipath.c
@@ -772,6 +772,7 @@ int scsi_mpath_dev_alloc(struct scsi_device *sdev)
 	} else {
 		sdev->scsi_mpath_dev->alua_state = SCSI_ACCESS_STATE_OPTIMAL;
 	}
+	sdev->access_state = sdev->scsi_mpath_dev->alua_state;
 
 	sdev->scsi_mpath_dev->index = ida_alloc(&scsi_mpath_head->ida, GFP_KERNEL);
 	if (sdev->scsi_mpath_dev->index < 0) {
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 3b03ee00c8df3..e4fbf08e05f4f 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -1113,7 +1113,7 @@ sdev_show_access_state(struct device *dev,
 	unsigned char access_state;
 	const char *access_state_name;
 
-	if (!sdev->handler)
+	if (!sdev->handler && !sdev->scsi_mpath_dev)
 		return -EINVAL;
 
 	access_state = (sdev->access_state & SCSI_ACCESS_STATE_MASK);
-- 
2.43.5

On 3/10/26 12:49, John Garry wrote:
> Now that ALUA is supported, we can maintain sdev->access_state.
> 
> However, preferred_path is still not maintained as that that is related
> to transitioning  state and we do not yet support that (for SCSI
> multipath).
> 
There is an issue with the preferred path in general, namely that it 
overlays the ALUA states (ie you can have 'acive/non-optimized' _and_
the preferred path bit set). So it only makes sense for explicit ALUA
as then the preferred path bit gives us an indicator that we might /
should switch paths.

If we restrict ourselves to implicit ALUA (which I'm advocating anyway
for scsi-multipath) the preferred path becomes rather pointless as
we cannot influence path selection at all.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.com                               +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

On 10/03/2026 13:27, Hannes Reinecke wrote:
>> However, preferred_path is still not maintained as that that is related
>> to transitioning  state and we do not yet support that (for SCSI
>> multipath).
>>
> There is an issue with the preferred path in general, namely that it 
> overlays the ALUA states (ie you can have 'acive/non-optimized' _and_
> the preferred path bit set). So it only makes sense for explicit ALUA
> as then the preferred path bit gives us an indicator that we might /
> should switch paths.
> 
> If we restrict ourselves to implicit ALUA (which I'm advocating anyway
> for scsi-multipath) the preferred path becomes rather pointless as
> we cannot influence path selection at all.

ok, fine, I won't touch for native scsi multipath.

Thanks