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

[Brian Bunker <brian@purestorage.com>]

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.

> 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.

> 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.

Thanks,

Brian