From: Brian Bunker <brian@purestorage.com>
To: linux-scsi@vger.kernel.org
Cc: "Martin K . Petersen" <mkp@kernel.org>,
"James E . J . Bottomley" <James.Bottomley@HansenPartnership.com>,
Hannes Reinecke <hare@kernel.org>,
Bart Van Assche <bvanassche@acm.org>,
Krishna Kant <krishna.kant@purestorage.com>
Subject: [PATCH v2 0/4] scsi: Bind sd to LUs in the ALUA unavailable state
Date: Wed, 28 Oct 2026 16:08:03 -0700 [thread overview]
Message-ID: <20261028230807.61578-1-brian@purestorage.com> (raw)
A LU that is in the ALUA unavailable state on a target port reports
peripheral qualifier 001b in its INQUIRY data. scsi_bus_match() only
matches devices with peripheral qualifier 000b, so if a host scans such
a path, no upper-level driver is ever bound to it. When the target port
later becomes available, nothing binds sd and the path stays unusable
until the device is deleted and rescanned. A host that was already
running when the path became unavailable keeps sd bound, so the result
depends on when the host scanned.
This series fixes that at scan time. The SCSI core reads the ALUA access
state of a device with REPORT TARGET PORT GROUPS before the device is
registered, and matches sd to PQ 001b devices whose access state could
be read. SPC-4 requires PQ 001b in the unavailable state, and the
command fails for an unmapped LUN, so these are taken to be mapped LUs
that are unavailable. This is the same situation as a path in the
standby state, to which sd already binds. The path then stays in the
multipath map as a
failed path, and the existing UNIT ATTENTION handling brings it back
when the target port becomes available.
PQ 001b cannot be matched on its own: an unmapped LUN reports it as
well, and some targets report every possible LUN in REPORT LUNS. Binding
sd to all of those would create disks with no backing LU. An unmapped
LUN fails REPORT TARGET PORT GROUPS, so the access state is what tells
the two cases apart.
1/4 moves submit_rtpg() out of scsi_dh_alua into the SCSI core as
scsi_report_tpgs(), so the core can read the ALUA state of a
device itself. No functional change.
2/4 sends REPORT TARGET PORT GROUPS from scsi_add_lun() for a device
that reports TPGS support and sets sdev->access_state from the
descriptor of the target port group of this path.
3/4 starts a new port group in scsi_dh_alua in the access state the
core read, rather than active/optimized, so that no I/O is let
through to an unavailable path before the handler's first RTPG
completes.
4/4 matches PQ 001b devices whose access state could be read, which
are taken to be mapped LUs in the unavailable state.
This is an alternative to the series that refreshes the INQUIRY data
and reprobes the device on rescan ("scsi: Refresh INQUIRY data and
reprobe on rescan", v8 last posted). That series needs a way to update
the INQUIRY data of a live device and to reprobe it. This one does not
change the INQUIRY data after the device is discovered, and has no
reprobe, so none of the locking and ordering issues that came with
refreshing it.
The INQUIRY data in sysfs is unchanged by this series. It is read and
created once, when the device is discovered, and keeps the peripheral
qualifier reported at that time like the rest of the INQUIRY data. At
any given time that cached peripheral qualifier can be out of sync with
the device, for example after the target port moves between available
and unavailable. An INQUIRY sent to the device returns the current
value, and the access_state attribute shows the current ALUA state.
This does not make every target work. Today none does: a host that scans
a path while it is unavailable never binds sd to it. With this series a
target that answers sd's probe commands in that state is handled
correctly, and the others are no worse off. What it relies on, and the
known limits:
- SPC-4 requires PQ 001b in the unavailable state and requires REPORT
TARGET PORT GROUPS there. It does not say that PQ 001b is reported
only in that state, so a PQ 001b device whose access state could be
read is taken to be a mapped LU that is unavailable: an unmapped
LUN fails the command.
- The decision is made once, at scan, like the peripheral qualifier
itself. If REPORT TARGET PORT GROUPS fails (other than with UNIT
ATTENTION, which is retried), or the INQUIRY data and VPD page 0x83
do not allow it to be sent, nothing is matched, as before.
- SPC-4 requires neither READ CAPACITY nor, in the unavailable state,
MODE SENSE. alua_prep_fn() already fails normal I/O to such a path
without sending it, but sd's probe commands are passthrough
commands and are sent to the target. If a target rejects them, sd
keeps default values, such as a capacity of 0, until a later
revalidate, as it does for a standby path today. If the path
changes state while sd probes, it can also end up with a mix.
- The ALUA device handler starts a new port group in the state read at
scan. If the path changed since, that is stale until the first RTPG
of the handler completes.
- The standard INQUIRY data, including the peripheral qualifier and
what sd uses from it, is only read when the device is discovered;
the kernel has no mechanism to refresh it. A rescan, e.g. on the
INQUIRY DATA HAS CHANGED UNIT ATTENTION, reads the VPD pages again
and revalidates sd, but does not read the INQUIRY data again.
Changes since v1 (prompted by the Sashiko review of 4/4):
- 4/4: scsi_bus_match() no longer tests sdev->access_state. The
peripheral qualifier is read once when the device is scanned, but
access_state follows the ALUA state, so a device scanned in the
unavailable state stopped matching as soon as its path became
available: when an upper-level driver module is loaded later, when
a driver is rebound through sysfs, or when the ALUA device handler
updated access_state before sd was probed. scsi_add_lun() now
records in a new sdev->match_unavailable flag whether the device
reported PQ 001b and its access state could be read, and
scsi_bus_match() uses that. SPC-4 requires PQ 001b in the unavailable
state and an unmapped LUN fails the command, so this does not
depend on the state the command returns, which can already be
available if the path recovered between the INQUIRY and the
command.
- 1/4 to 3/4: No changes.
v1 cover-letter Message-ID: <20261028184216.25453-1-brian@purestorage.com>
Brian Bunker (4):
scsi: core: Move REPORT TARGET PORT GROUPS into the SCSI core
scsi: core: Read the ALUA access state when a device is scanned
scsi: scsi_dh_alua: Start a port group in the scanned access state
scsi: core: Match ULDs to logical units in the ALUA unavailable state
drivers/scsi/device_handler/scsi_dh_alua.c | 72 +++++---------
drivers/scsi/scsi_lib.c | 52 +++++++++++
drivers/scsi/scsi_scan.c | 103 +++++++++++++++++++++
drivers/scsi/scsi_sysfs.c | 14 ++-
include/scsi/scsi_device.h | 10 ++
include/scsi/scsi_proto.h | 3 +
6 files changed, 204 insertions(+), 50 deletions(-)
--
2.56.0
next reply other threads:[~2026-10-28 23:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 23:08 Brian Bunker [this message]
2026-10-28 23:08 ` [PATCH v2 1/4] scsi: core: Move REPORT TARGET PORT GROUPS into the SCSI core Brian Bunker
2026-10-28 23:08 ` [PATCH v2 2/4] scsi: core: Read the ALUA access state when a device is scanned Brian Bunker
2026-10-28 23:08 ` [PATCH v2 3/4] scsi: scsi_dh_alua: Start a port group in the scanned access state Brian Bunker
2026-10-28 23:19 ` sashiko-bot
2026-10-28 23:08 ` [PATCH v2 4/4] scsi: core: Match ULDs to logical units in the ALUA unavailable state Brian Bunker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261028230807.61578-1-brian@purestorage.com \
--to=brian@purestorage.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=bvanassche@acm.org \
--cc=hare@kernel.org \
--cc=krishna.kant@purestorage.com \
--cc=linux-scsi@vger.kernel.org \
--cc=mkp@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.