Re: [PATCH v8 0/5] scsi: Refresh INQUIRY data and reprobe on rescan

[Hannes Reinecke <hare@suse.de>]

On 10/21/26 8:50 PM, Brian Bunker wrote:
> On 10/21/26 12:45 PM, Hannes Reinecke wrote:
>> Aw. The mysteries of SPC. Can't you simply use 'Standby' state?
>> That would not require all this weird rescanning.
> 
> We do use standby today, and have since 2017. That is where the
> trouble is. SPC-4 5.15.2.4.4 says that in standby the device server
> "shall support those of the following commands that it supports while
> in the active/optimized primary target port asymmetric access state",
> and the list includes:
> 
>    l) PERSISTENT RESERVE IN;
>    m) PERSISTENT RESERVE OUT;
> 
> We support persistent reservations in active/optimized, so standby has
> to accept them too. When the link between the two arrays is down, the
> array that has stopped serving the volume can't mirror a reservation
> change to its peer, so it can't accept one without the two arrays
> ending up with different reservation state. Making standby work in
> that situation takes a lot of extra handling on the array. The
> unavailable list in 5.15.2.4.5 has no PR commands, which is exactly
> what this case needs.
> 
> Standby also isn't handled the same way by every host. ESX and AIX,
> for example, don't treat a path as down when RTPG reports it as
> standby; their path checkers keep trying to use it. So we carry
> OS-specific exceptions for how standby is presented to each host type.
> 
> ESX and AIX both handle unavailable. Linux is the one we can't use it
> with today, because of the problem this series addresses. If Linux
> handled it too, unavailable could be the rule for us, and most of the
> OS-specific code and the extra PR handling could go away. That is the
> motivation for doing this in Linux.
> 
> Bart, on Windows: I don't know how current Windows handles
> unavailable. If it still doesn't handle it well, we can keep using
> standby for Windows hosts, but that would be the one exception rather
> than the rule.
> 
>> Weelll ... an 'unavailable' device _never_ comes back.
>> The only chance it had to 'come back' would be to set a UNIT ATTENTION.
>> But that we will only ever see if we send commands to that device,
>> which we don't as it's unavailable ...
> [...]
>> What it the proposed strategy to get it back?
> 
> It depends on whether sd is bound, and after Bart's reply sd will stay
> bound on a running host (I've agreed to drop unbinding; see my reply to
> Bart from earlier today).
> 
>    - A host that was running when the path became unavailable keeps sd
>      bound. This is the case you describe for standby: the multipath
>      map stays intact, multipathd's path checker keeps polling the
>      path, and when the array leaves unavailable the UNIT ATTENTIONs it
>      posts (ALUA state changed, INQUIRY DATA HAS CHANGED) are seen on
>      those polls and the path is reinstated.
> 
>    - A host that scanned while the path was unavailable has no sd on
>      it, so nothing polls it, and you're right that a UNIT ATTENTION
>      alone would never be seen. For that case the array makes the host
>      look again when it leaves unavailable: on iSCSI it sends an
>      asynchronous event with REPORTED LUNS DATA HAS CHANGED, and iscsid
>      rescans each device on the session; on FC it logs out the
>      initiators, and the transport scans the target after the re-login.
>      That rescan is where v9 binds sd.
> 
>> Also we have to worry about the implications for multipathing:
>> If the device is set to 'unavailable' we'll be disconnecting it
>> from multipathing as the 'sd' driver will be detached.
> 
> With unbinding dropped, that no longer happens. A bound path stays in
> the map as a failed path, as it would in standby.
> 
Hmm.
But if you want to have this behaviour it would make sense to modify
scsi_bus_match() to extend to pqual 01b, too; then 'sd' would stay
bound to the scsi device even after rescan, and we wouldn't need
to worry about driver detaching and multipathd becoming inoperational.

>> When do you do the LOGO? When entering the unavaiblable state?
>> Or when resetting it back to normal?
> 
> When leaving unavailable. Entering it, the array only posts INQUIRY
> DATA HAS CHANGED and the ALUA state change; sd is bound and sees them
> on its next command. Leaving it, the array posts both UNIT ATTENTIONs
> and then, on FC, logs out the initiators so that a host with no sd on
> the path rescans.
> 
Ah. That'll explain it.

>> Yes, but that was the point.
>> If reprobe fails, what are you going to do?
>> You cannot 'magically' get it back, as _normally_ you would do a reprobe
>> to get it back. But that failed. So you _really_ need to delete that
>> device and restart from scratch.
> 
> In v9 the reprobe only ever binds a driver to a LU that has none. If
> the bind fails, the device is left in the state it was already in: a
> scsi_device with no ULD, exactly what the scan creates for a PQ = 1 LU.
> Nothing that worked before is lost, and the next rescan the array
> triggers tries again. Deleting the device and scanning from scratch
> would end at the same sd probe, so I'd rather log the failure and leave
> the device for the next rescan than add a removal path.
> 
Which if fine (I think).
But still it might be worthwhile exploring the idea of extending
scsi_bus_match(), as that will solve any ambiguity with 'sd' attaching
to the device.

Cheers,

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