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

[Brian Bunker <brian@purestorage.com>]

On 10/20/26 3:09 PM, Bart Van Assche wrote:
> This is a big behavior change. I prefer not to unbind disks if PQ
> changes.

OK, no unbinding. v9 will never detach a driver from a bound disk.

> Having taken another look at the cover letter makes me wonder whether
> it is really necessary to refetch standard INQUIRY data and reprobe the
> device when the peripheral qualifier or device type has changed?
> [...] When I was working on active/active SCSI arrays myself we
> didn't care about the INQUIRY data in the kernel and let multipathd
> figure out which path(s) to use.

I'd like multipathd to make that decision too. The problem is a path it
never gets to see. If a host scans while the array reports PQ = 1 on a
path, scsi_bus_match() doesn't bind sd, so the path has no block device
and multipathd doesn't know it exists. When the array returns to
PQ = 0, nothing binds sd, and the path stays unusable until someone
deletes the device and rescans. User space can't fix that; only the
kernel can bind sd.

The array has no choice about PQ = 1 here. SPC-4 5.15.2.4.5 requires it
in the unavailable state:

  a) INQUIRY (the peripheral qualifier (see 6.6.2) shall be set to
     001b);

We discussed this in "The PQ=1 saga" thread Martin started in January
2023. The simplest fix, letting scsi_bus_match() bind at PQ = 1, came
up there, and Martin pointed out that some arrays rely on PQ = 1 to
keep a ULD from binding and that keying off TPGS is probably not
enough. The IBM 2145 case behind 948e922fc446 (since reverted) shows
why: it returns PQ = 1 with PDT 0 for LUNs that aren't mapped. So I'm
not proposing that.

What came out of that thread instead was to reprobe the device when it
leaves the unavailable state. Martin suggested triggering a re-probe on
the transition, and you suggested a rescan when the ALUA state goes
from unavailable or standby to an active state. With unbinding off the
table, that is all v9 needs to do:

  - Only logical units with no driver bound are refreshed. A bound
    disk is left exactly as it is today: no INQUIRY refetch, no
    reprobe.

  - If the refreshed INQUIRY data shows PQ = 0, the driver is bound.
    Nothing is ever unbound.

The trigger has to come from the target, because a LU with no driver
bound gets no commands, so no UNIT ATTENTION or ALUA state change
reaches it. Our arrays make the host rescan when they leave
unavailable, the same way they do when the first volume is mapped to a
host. On iSCSI they send an asynchronous event with REPORTED LUNS DATA
HAS CHANGED, and iscsid writes to the sysfs rescan attribute of every
device on the session, which ends up in scsi_rescan_device(). On FC
they log out the host's initiators, and after the re-login the
transport scans the target. That scan finds the existing scsi_device
and today does nothing with it, so the scan path calls
scsi_rescan_device() for registered devices that have no driver bound.
Bound devices skip it, so the scan cost and the time scan_mutex is held
don't change for them.

That leaves one difference you should know about. While a path is
unavailable, a host that was running when it became unavailable keeps
a bound sd on that path, which ALUA and multipathd treat as a failed
path. A host that scanned while it was unavailable has no sd on it.
Both end up the same once the array returns to PQ = 0.

This makes v9 much smaller than v8: no unbind, no offline handling,
and no INQUIRY update on a device that has a driver bound. The fixes
you and Sashiko found still apply where the code remains
(device_is_registered() before binding, the inquiry_len handling, the
PQ 3 / PDT 1Fh filters, and the structural points).

Martin, does this direction work for you before I write it?

Thanks,

Brian