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

[Brian Bunker <brian@purestorage.com>]

On 10/22/26 1:56 PM, Hannes Reinecke wrote:
> 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.
[...]
> 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.

I agree, and I'd much rather do that than the reprobe. It was my first
idea in "The PQ=1 saga" thread in 2023, but matching PQ = 1 on its own
isn't safe, and I think I now understand why Martin pushed back then.

PQ = 001b has two meanings. One is the ALUA unavailable state, which
SPC-4 5.15.2.4.5 a) requires. The other is a LUN that isn't mapped to
the initiator at all. SPC-4 6.6.1 says:

  In response to an INQUIRY command received by an incorrect logical
  unit, the SCSI target device shall return the INQUIRY data with the
  peripheral qualifier set to the value defined in 6.6.2. The device
  server shall terminate an INQUIRY command with CHECK CONDITION
  status only if the device server is unable to return the requested
  INQUIRY data.

So the INQUIRY succeeds, and 6.6.2 decides the qualifier. An array
can map a volume at any of its LUNs, so 011b ("The device server is
not capable of supporting a peripheral device on this logical unit")
would be wrong. 001b is the correct answer for a LUN that could hold a
volume but currently doesn't:

  001b  A peripheral device having the indicated peripheral device type
        is not connected to this logical unit. However, the device
        server is capable of supporting the indicated peripheral device
        type on this logical unit.

An array that returns PQ = 1 for an unmapped LUN is therefore doing
exactly what the standard says. The trap is set elsewhere, by REPORT
LUNS. Some arrays, at least in the past, returned a full LUN list
(0 to 255) in REPORT LUNS and left it to the initiator to work out
which LUNs were really there. Linux then sends INQUIRY to every one of
them and, correctly, gets PQ = 1 back from all the unmapped ones. Binding sd at
PQ = 1 would turn each of those into a disk with nothing behind it: no
READ CAPACITY, no logical block size. I suspect that is the experience
behind Martin's "there are also storage arrays out there that rely on
PQ=1 to inhibit devices being claimed", and the IBM 2145 case in
948e922fc446 (PQ = 1, PDT 0 for a LUN that isn't mapped) looks like
the same thing.

Checking TPGS doesn't help, because the TPGS bits come from the same
INQUIRY response. The array fills in the standard INQUIRY data for an
unmapped LUN the same way it does for a mapped one.

A command other than INQUIRY does tell the two apart. A LUN that isn't
mapped rejects REPORT TARGET PORT GROUPS with LOGICAL UNIT NOT
SUPPORTED, while a LU in the unavailable state must accept it
(5.15.2.4.5 c)) and reports its target port group as unavailable.

The ALUA handler is already in the right place to send it.
scsi_sysfs_add_sdev() calls scsi_dh_add_device() before device_add(),
so scsi_dh_alua has attached before scsi_bus_match() runs. The only
thing missing is the RTPG result: alua_check_vpd() queues the first
RTPG with alua_rtpg_queue(), so it normally completes after the device
has been matched.

So my proposal is:

  - In scsi_dh_alua, for a device that reported PQ = 1, send the first
    RTPG synchronously at attach time and set sdev->access_state from
    that device's own response. An unmapped LUN fails the RTPG and
    stays as it is today. The queued RTPG and the shared port group
    handling stay as they are, so an unmapped LUN can't pick up
    another LU's state from the port group.

  - In scsi_bus_match(), match PQ = 0 as today, and also PQ = 1 when
    access_state says unavailable.

sd then binds to an unavailable path whether the host was running when
the path became unavailable or scanned while it was. The path stays in
the multipath map as a failed path, multipathd keeps polling it, and
the existing UNIT ATTENTION handling brings it back, as you described.
This relies on scsi_dh_alua being attached at scan time (built in, or
loaded before the scan), which I think is how it should work anyway.

It would replace the v8 reprobe completely: no INQUIRY refresh, no
reprobe, and no change to the scan path.

Would you take a synchronous first RTPG in alua_check_vpd() for PQ = 1
devices? If you'd rather keep the handler as it is, the alternative is
for the SCSI core to send a TEST UNIT READY to PQ = 1 LUNs during the
scan and look for LOGICAL UNIT NOT ACCESSIBLE, TARGET PORT IN
UNAVAILABLE STATE, but I think the handler is the better place for it.

Thanks,

Brian