mbox series

[RFC,0/3] sg3_utils: udev rules: restrict use of ambiguous device IDs

Message ID 20230327132459.29531-1-mwilck@suse.com (mailing list archive)
Headers show
Series sg3_utils: udev rules: restrict use of ambiguous device IDs | expand

Message

Martin Wilck March 27, 2023, 1:24 p.m. UTC
From: Martin Wilck <mwilck@suse.com>

Most modern SCSI devices provide VPD page 83 with at least one highly
reliable device identifier, like NAA Registered Extended or EUI-64, or
the ata-id identifier. Other device identifier types have shown to be less
reliable and possibly ambiguous. Ambiguity in particular is a problem with
multipath-tools, which may group unrelated devices together in a multipath
map, causing possible data corruption.

The device identifiers are used in two independent ways by the udev rules:
a) to set ID_SERIAL for subsystems like multipath, and b) to create
/dev/disk/by-id/scsi-... symlinks. Our udev rules have traditionally created
symlinks for every device identifier obtained from either VPD 83 or 80. This
may cause issues, especially on large installments with storage devices that
exhibit the same identifier for many logical units. At the same time, these
symlinks are rarely used.

Avoid using unreliable identifiers for setting ID_SERIAL, and don't create
symlinks for these identifiers. Add a configuration method that allows
users to easily re-enable these methods and symlinks if they need to
(this might be the case on systems with legacy devices that are referenced
in /etc/crypttab, lvm.conf, or the like). This is done by introducing
environment variables .SCSI_ID_SERIAL_SRC and .SCSI_ID_SYMLINK_SRC, to
control use of device identifiers for determining ID_SERIAL and for creating
symlinks, respectively. Both variables can contain the letters "T", "L", "V",
and "S" to enable T10-vendor ID, NAA local ID, vendor-specific ID, and VPD 80
based ID, respectively.

Distributions can change the defaults for these environment variables
to provide backward compatibility for their users, while offering users
an easy way to change the settings.

I'm sending this as RFC, because I expect that not everyone will agree
which identifiers should be enabled by default.


Martin Wilck (3):
  55-scsi-sg3_id.rules: don't set unreliable device ID by default
  58-scsi-sg3_symlink.rules: don't create extra by-id symlinks by
    default
  udev: add 00-scsi-sg3_config.rules for user configuration

 Makefile.am                       |  1 +
 scripts/00-scsi-sg3_config.rules  | 23 ++++++++++++++
 scripts/55-scsi-sg3_id.rules      | 53 ++++++++++++++++++++++++++++---
 scripts/58-scsi-sg3_symlink.rules | 46 +++++++++++++++++++++------
 4 files changed, 109 insertions(+), 14 deletions(-)
 create mode 100644 scripts/00-scsi-sg3_config.rules

Comments

Douglas Gilbert March 27, 2023, 11:58 p.m. UTC | #1
On 2023-03-27 09:24, mwilck@suse.com wrote:
> From: Martin Wilck <mwilck@suse.com>
> 
> Most modern SCSI devices provide VPD page 83 with at least one highly
> reliable device identifier, like NAA Registered Extended or EUI-64, or
> the ata-id identifier. Other device identifier types have shown to be less
> reliable and possibly ambiguous. Ambiguity in particular is a problem with
> multipath-tools, which may group unrelated devices together in a multipath
> map, causing possible data corruption.
> 
> The device identifiers are used in two independent ways by the udev rules:
> a) to set ID_SERIAL for subsystems like multipath, and b) to create
> /dev/disk/by-id/scsi-... symlinks. Our udev rules have traditionally created
> symlinks for every device identifier obtained from either VPD 83 or 80. This
> may cause issues, especially on large installments with storage devices that
> exhibit the same identifier for many logical units. At the same time, these
> symlinks are rarely used.
> 
> Avoid using unreliable identifiers for setting ID_SERIAL, and don't create
> symlinks for these identifiers. Add a configuration method that allows
> users to easily re-enable these methods and symlinks if they need to
> (this might be the case on systems with legacy devices that are referenced
> in /etc/crypttab, lvm.conf, or the like). This is done by introducing
> environment variables .SCSI_ID_SERIAL_SRC and .SCSI_ID_SYMLINK_SRC, to
> control use of device identifiers for determining ID_SERIAL and for creating
> symlinks, respectively. Both variables can contain the letters "T", "L", "V",
> and "S" to enable T10-vendor ID, NAA local ID, vendor-specific ID, and VPD 80
> based ID, respectively.
> 
> Distributions can change the defaults for these environment variables
> to provide backward compatibility for their users, while offering users
> an easy way to change the settings.
> 
> I'm sending this as RFC, because I expect that not everyone will agree
> which identifiers should be enabled by default.

Lets see if anything happens. Applied as sg3_utils revision 1019 and
pushed to https://github.com/doug-gilbert/sg3_utils .

Didn't see any effect on an Ubuntu 22.10 when sg3_utils deb package
built and installed. No sign of 00-scsi-sg3_config.rules being placed
anywhere by Ubuntu. Does Suse install those rules?

Doug Gilbert

> Martin Wilck (3):
>    55-scsi-sg3_id.rules: don't set unreliable device ID by default
>    58-scsi-sg3_symlink.rules: don't create extra by-id symlinks by
>      default
>    udev: add 00-scsi-sg3_config.rules for user configuration
> 
>   Makefile.am                       |  1 +
>   scripts/00-scsi-sg3_config.rules  | 23 ++++++++++++++
>   scripts/55-scsi-sg3_id.rules      | 53 ++++++++++++++++++++++++++++---
>   scripts/58-scsi-sg3_symlink.rules | 46 +++++++++++++++++++++------
>   4 files changed, 109 insertions(+), 14 deletions(-)
>   create mode 100644 scripts/00-scsi-sg3_config.rules
>
Martin Wilck March 28, 2023, 7:52 a.m. UTC | #2
On Mon, 2023-03-27 at 19:58 -0400, Douglas Gilbert wrote:
> 
> Lets see if anything happens. Applied as sg3_utils revision 1019 and
> pushed to https://github.com/doug-gilbert/sg3_utilsĀ .
> 
> Didn't see any effect on an Ubuntu 22.10 when sg3_utils deb package
> built and installed. No sign of 00-scsi-sg3_config.rules being placed
> anywhere by Ubuntu. Does Suse install those rules?

No, not yet. That's why I sent these patches, I intend to get rid of
the legacy symlinks on openSUSE with upstream's blessing.

Regards,
Martin