From: mwilck@suse.com
To: Douglas Gilbert <dgilbert@interlog.com>, Hannes Reinecke <hare@suse.de>
Cc: James Bottomley <jejb@linux.vnet.ibm.com>,
linux-scsi@vger.kernel.org,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Franck Bui <fbui@suse.de>,
dm-devel@redhat.com, Martin Wilck <mwilck@suse.com>
Subject: [dm-devel] [PATCH 1/3] 55-scsi-sg3_id.rules: don't set unreliable device ID by default
Date: Mon, 27 Mar 2023 15:24:57 +0200 [thread overview]
Message-ID: <20230327132459.29531-2-mwilck@suse.com> (raw)
In-Reply-To: <20230327132459.29531-1-mwilck@suse.com>
From: Martin Wilck <mwilck@suse.com>
Some of the methods to determine the SCSI device ID are known to be
unreliable and, and possibly cause dm-multipath to falsely detect
a multipath setup and cause data corruption. These methods will
only be used if the known reliable device IDs (like NAA registered)
are unavailable.
Don't apply these methods by default. Make the methods to use configurable
instead. Configuration is done by setting the udev property
".SCSI_ID_SERIAL_SRC" to any combination of the letters T, L, V, S:
T: T10 vendor ID ("1...")
L: NAA local ("33...")
V: vendor-specific ("0...")
S: vendor/model/serial number ("S...")
The ordering of the letters in .SCSI_ID_SERIAL_SRC doesn't matter,
the precedence is always T, L, V, S.
Regardless of using these properties for ID_SERIAL, we can infer that
if any of these properties is set, it's correct to set ID_BUS="scsi".
Signed-off-by: Martin Wilck <mwilck@suse.com>
---
scripts/55-scsi-sg3_id.rules | 53 +++++++++++++++++++++++++++++++++---
1 file changed, 49 insertions(+), 4 deletions(-)
diff --git a/scripts/55-scsi-sg3_id.rules b/scripts/55-scsi-sg3_id.rules
index 453210b..33b2ad3 100644
--- a/scripts/55-scsi-sg3_id.rules
+++ b/scripts/55-scsi-sg3_id.rules
@@ -99,11 +99,56 @@ ENV{ID_SERIAL}!="?*", ENV{SCSI_IDENT_LUN_NAA_REG}=="?*", ENV{ID_BUS}="scsi", ENV
ENV{ID_SERIAL}!="?*", ENV{SCSI_IDENT_LUN_NAA_EXT}=="?*", ENV{ID_BUS}="scsi", ENV{ID_SERIAL}="3$env{SCSI_IDENT_LUN_NAA_EXT}", ENV{ID_SERIAL_SHORT}="$env{SCSI_IDENT_LUN_NAA_EXT}"
ENV{ID_SERIAL}!="?*", ENV{SCSI_IDENT_LUN_EUI64}=="?*", ENV{ID_BUS}="scsi", ENV{ID_SERIAL}="2$env{SCSI_IDENT_LUN_EUI64}", ENV{ID_SERIAL_SHORT}="$env{SCSI_IDENT_LUN_EUI64}"
ENV{ID_SERIAL}!="?*", ENV{SCSI_IDENT_LUN_NAME}=="?*", ENV{ID_BUS}="scsi", ENV{ID_SERIAL}="8$env{SCSI_IDENT_LUN_NAME}", ENV{ID_SERIAL_SHORT}="$env{SCSI_IDENT_LUN_NAME}"
-ENV{ID_SERIAL}!="?*", ENV{SCSI_IDENT_LUN_T10}=="?*", ENV{ID_BUS}="scsi", ENV{ID_SERIAL}="1$env{SCSI_IDENT_LUN_T10}", ENV{ID_SERIAL_SHORT}="$env{SCSI_IDENT_LUN_T10}"
-ENV{ID_SERIAL}!="?*", ENV{SCSI_IDENT_LUN_NAA_LOCAL}=="?*", ENV{ID_BUS}="scsi", ENV{ID_SERIAL}="3$env{SCSI_IDENT_LUN_NAA_LOCAL}", ENV{ID_SERIAL_SHORT}="$env{SCSI_IDENT_LUN_NAA_LOCAL}"
-ENV{ID_SERIAL}!="?*", ENV{SCSI_IDENT_LUN_VENDOR}=="?*", ENV{ID_BUS}="scsi", ENV{ID_SERIAL}="0$env{SCSI_VENDOR}_$env{SCSI_MODEL}_$env{SCSI_IDENT_LUN_VENDOR}", ENV{ID_SERIAL_SHORT}="$env{SCSI_IDENT_LUN_VENDOR}"
-ENV{ID_SERIAL}!="?*", ENV{SCSI_IDENT_SERIAL}=="?*", ENV{ID_BUS}="scsi", ENV{ID_SERIAL}="S$env{SCSI_VENDOR}_$env{SCSI_MODEL}_$env{SCSI_IDENT_SERIAL}", ENV{ID_SERIAL_SHORT}="$env{SCSI_IDENT_SERIAL}"
# Compat ID_SCSI_SERIAL setting
ENV{ID_SCSI_SERIAL}!="?*", ENV{SCSI_IDENT_SERIAL}=="?*", ENV{ID_SCSI_SERIAL}="$env{SCSI_IDENT_SERIAL}"
+
+# Enable or disable possibly ambiguous SCSI device ID sources for setting ID_SERIAL
+#
+# .SCSI_ID_SERIAL_SRC can be any combination of the characters "TLVS":
+# T: T10 vendor ID ("1...") from VPD 0x83
+# L: NAA local ("33...") from VPD 0x83
+# V: vendor-specific ("0...") from VPD 0x83
+# S: vendor/model/serial number ("S...") from VPD 0x80
+# The ordering of the letters doesn't matter, the precedence is always T, L, V, S
+# NAA (except "local") and EUI-64 IDs (see below), as well as ATA IDs, always take precedence over
+# the sources configured here.
+#
+# This only needs to be changed if there are legacy SCSI devices that don't provide any reliable
+# device identifiers, and some subsystem like multipath requires that ID_SERIAL is set.
+# Be aware that multipath actually needs unique identifiers, though.
+# Using ambiguous identifiers for ID_SERIAL can cause data corruption with multipath.
+#
+# To configure this, add an early rule (e.g. /etc/udev/rules.d/00-scsi-serial.rules) e.g. like this:
+# ACTION!="remove", KERNEL=="sd*|sr*|st*|nst*|cciss*", ENV{.SCSI_ID_SERIAL_SRC}="TLVS"
+#
+# By default, only T10 vendor ID is allowed.
+ENV{.SCSI_ID_SERIAL_SRC}!="?*", ENV{.SCSI_ID_SERIAL_SRC}="T"
+
+ENV{ID_SERIAL}=="?*", GOTO="sg3_utils_id_end"
+ENV{SCSI_IDENT_LUN_T10}=="?*", ENV{ID_BUS}="scsi"
+ENV{SCSI_IDENT_LUN_T10}=="?*", ENV{.SCSI_ID_SERIAL_SRC}=="*T*", \
+ ENV{ID_SERIAL}="1$env{SCSI_IDENT_LUN_T10}", \
+ ENV{ID_SERIAL_SHORT}="$env{SCSI_IDENT_LUN_T10}"
+
+ENV{ID_SERIAL}=="?*", GOTO="sg3_utils_id_end"
+ENV{SCSI_IDENT_LUN_NAA_LOCAL}=="?*", ENV{ID_BUS}="scsi"
+ENV{SCSI_IDENT_LUN_NAA_LOCAL}=="?*", ENV{.SCSI_ID_SERIAL_SRC}=="*L*", \
+ ENV{ID_SERIAL}="3$env{SCSI_IDENT_LUN_NAA_LOCAL}", \
+ ENV{ID_SERIAL_SHORT}="$env{SCSI_IDENT_LUN_NAA_LOCAL}"
+
+ENV{ID_SERIAL}=="?*", GOTO="sg3_utils_id_end"
+ENV{SCSI_IDENT_LUN_VENDOR}=="?*", ENV{ID_BUS}="scsi"
+ENV{SCSI_IDENT_LUN_VENDOR}=="?*", ENV{.SCSI_ID_SERIAL_SRC}=="*V*", \
+ ENV{ID_SERIAL}="0$env{SCSI_VENDOR}_$env{SCSI_MODEL}_$env{SCSI_IDENT_LUN_VENDOR}", \
+ ENV{ID_SERIAL_SHORT}="$env{SCSI_IDENT_LUN_VENDOR}"
+
+ENV{ID_SERIAL}=="?*", GOTO="sg3_utils_id_end"
+ENV{SCSI_IDENT_SERIAL}=="?*", ENV{ID_BUS}="scsi"
+ENV{SCSI_IDENT_SERIAL}=="?*", ENV{.SCSI_ID_SERIAL_SRC}=="*S*", \
+ ENV{ID_SERIAL}="S$env{SCSI_VENDOR}_$env{SCSI_MODEL}_$env{SCSI_IDENT_SERIAL}", \
+ ENV{ID_SERIAL_SHORT}="$env{SCSI_IDENT_SERIAL}"
+
LABEL="sg3_utils_id_end"
+ENV{ID_SERIAL}!="?*", ENV{DEVTYPE}=="disk", \
+ PROGRAM="/bin/logger -t 55-scsi-sg3_id.rules -p daemon.warning \"WARNING: SCSI device %k has no device ID, consider changing .SCSI_ID_SERIAL_SRC in 00-scsi-sg3_config.rules\""
--
2.39.2
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2023-03-27 13:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-27 13:24 [dm-devel] [RFC PATCH 0/3] sg3_utils: udev rules: restrict use of ambiguous device IDs mwilck
2023-03-27 13:24 ` mwilck [this message]
2023-03-27 13:24 ` [dm-devel] [PATCH 2/3] 58-scsi-sg3_symlink.rules: don't create extra by-id symlinks by default mwilck
2023-03-27 13:24 ` [dm-devel] [PATCH 3/3] udev: add 00-scsi-sg3_config.rules for user configuration mwilck
2023-03-27 23:58 ` [dm-devel] [RFC PATCH 0/3] sg3_utils: udev rules: restrict use of ambiguous device IDs Douglas Gilbert
2023-03-28 7:52 ` Martin Wilck
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=20230327132459.29531-2-mwilck@suse.com \
--to=mwilck@suse.com \
--cc=dgilbert@interlog.com \
--cc=dm-devel@redhat.com \
--cc=fbui@suse.de \
--cc=hare@suse.de \
--cc=jejb@linux.vnet.ibm.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).