On Sunday 08 October 2023, Joe Salmeri wrote:
...
I know that the /dev/sdX drive mappings are not guaranteed to be the same at every boot, however, this is the first time they have have mapped out differently on my system ( which has had no HW updates or any updates other than TW for quite a while ).
It would seeem that either something in TW20231001 or probably kernel 6.5.4-1 is the source of this.
I think the cause may be sg3_utils moving to v1.48. I tracked down the mailing list post that I took to describe the reason I was dumped into emergency mode at boot. The mailing list archive does not seem to contain this post and an important follow up post. I could neither locate the posts by browsing or searching the archive, but perhaps I'm doing something wrong. Anyway, I'll quote both posts here (I will also reply to the original to bump it up): --- Original quoted post --- SCSI device identification and SCSI symlink generation in sg3_utils 1.48 Date: 2023-09-22 10:22 From: Martin Wilck via openSUSE Factory <factory@lists.opensuse.org> To: "opensuse-factory" <opensuse-factory@opensuse.org> CC: Hannes Reinecke <hare@suse.de>, Franck Bui <fbui@suse.com> Reply to: Martin Wilck <mwilck@suse.com> With the forthcoming update of sg3_utils to v1.48 (currently in Base:System, to be submitted to Factory soon), SCSI device identification and SCSI symlink generation by udev will change. TL;DR: unreliable device identifiers will not be used by default any more, and /dev/disk/by-id symlinks for such identifiers will not be created by default, either. The policy can be changed by editing the udev rules in 00-scsi-sg3_config.rules. Please file bugs and / or notify me if you have trouble with this new identification scheme. Of course, while this is still in Base:System, we can also discuss the general approach for Factory, and the defaults to be applied. Long version: It is well known that referring to disk devices by their device node (like /dev/sda) is unreliable. In most situations, it is recommended to refer to devices by their content, i.e. using file system UUIDs or labels. Sometimes, however, the devices must be referred to by hardware properties. For this purpose, udev maintains various symlinks under /dev/disk/by-id. This post is specifically about SCSI symlinks, which have the format /dev/disk/by-id/scsi-XYZ. If you don't use dm-multipath, and don't use hardware IDs to refer to any disks or partitions anywhere, you can stop reading here. SCSI devices can be identified in different ways by the contents of SCSI VPD (Vital Product Data) pages. In PVD 83 (device identification), the following identifiers may occur (see SCSI spec SPC-6 §7.7.6 for details): a) NAA registered extended: 36... (+ 31 hex digits) b) NAA registered: 35... (+ 15 hex digits) c) NAA extended: 32... (+ 15 hex digits) d) EUI-64: 2... (+ 16 hex digits) e) SCSI name string: 8... (+ utf-8 string) f) NAA local ("L"): 33... (+ 15 hex digits) g) T10 vendor-ID ("T): 1... (+ string) h) vendor-specific ("V") 0... (+ string) Furthermore, we have i) serial number ("S"): S... (+ vendor/product/serial string) The list above is sorted roughly top-down by the reliability (uniqueness) of these identifiers. The udev rules select the most reliable available identifier from the above list to set the ID_SERIAL udev property, which is used e.g. by dm-multipath to identify SCSI devices which represent different paths to the same physical volume. Furthermore, the udev rules create /dev/disk/by-id/scsi-$ID symlinks for all identifiers from the above list that are defined for a given device. This makes sure that whatever identifier a user has chosen for referring to her disks will be available as symlink under /dev/disk/by-id. However, this has also severe disadvantages. The identifiers f)-i) are not reliable; IOW there can be multiple devices in the same system that use the same identifier, although they don't represent the same physical disk. This applies to i) in particular: Some large storage arrays use the same serial number for all LUNs they expose. Using such identifiers for multipath can cause fatal data corruption. Moreover, the creation of these symlinks during boot can slow down booting a lot, because thousands of devices may be contending for the same symlink. Lastly, not creating useless symlinks will tidy up /dev/disk/by-id and make it easier to read. Therefore sg3_utils 1.48 changes the policy for SCSI device identification. The policy can be customized in the udev rule "00-scsi- sg3_config.rules" (to change the policy, copy this file from /usr/lib/udev/rules.d to /etc/udev/rules.d first). For determining ID_SERIAL, only a)-e) above are tried. If users need to use additional identifiers from the list above, they can set the udev property .SCSI_ID_SERIAL_SRC (leading "." is intentional) to any combination of the capital letters in quotes in the list above. E.g. "ST" would mean to take g) and i) into account. To restore the previous behavior, set ENV{.SCSI_ID_SERIAL_SRC}="LTVS". The current upstream default is "T", so that g) above is still enabled. To disable all "unreliable" IDs, set it to the empty string. If udev encounters a device for which ID_SERIAL can't be assigned, it prints a warning to the journal. Symlink generation is controlled by the variable .SCSI_SYMLINK_SRC. It can also be set to any combination of "LTVS", with the same meaning of the letters as above, and controls which scsi-... symlinks udev will create under /dev/disk/by-id/, *in addition* to the symlink /dev/disk/by-id/scsi-$ID_SERIAL, which will always be created if ID_SERIAL could be determined. Again, to restore the previous behavior of the udev rules, set ENV{.SCSI_SYMLINK_SRC}="LTVS". The default is the empty string. Note 1: The symlink generation applies to both disks and partitions. Partition symlinks have a "-part$P" string appended to the name of the symlink of their parent disk. Note 2: Modern SCSI devices usually support one or more of the "reliable" identifiers a)-e) above. I expect that only very few old devices really need one of f)-i). Inform me if you find counter- examples. Note 3: ATA and USB devices have additional identifiers generated by the transport (/dev/disk/by-id/ata-* and /dev/disk/by-id/usb-*) which are unaffected by this change. These devices often don't expose proper SCSI IDs, but they actually don't need them because the ATA or USB identifiers are unique. Regards, Martin --- Most recent quoted post --- Re: SCSI device identification and SCSI symlink generation in sg3_utils 1.48 Date: 2023-09-29 05:03 From: Martin Wilck via openSUSE Factory <factory@lists.opensuse.org> To: factory@lists.opensuse.org Reply to: Martin Wilck <mwilck@suse.com> On Fri, 2023-09-22 at 00:22 +0200, Martin Wilck via openSUSE Factory wrote:
With the forthcoming update of sg3_utils to v1.48 (currently in Base:System, to be submitted to Factory soon), SCSI device identification and SCSI symlink generation by udev will change.
TL;DR: unreliable device identifiers will not be used by default any more, and /dev/disk/by-id symlinks for such identifiers will not be created by default, either. The policy can be changed by editing the udev rules in 00-scsi-sg3_config.rules.
To make sure this information isn't buried in the mailing list, I've created https://en.opensuse.org/SDB:SCSI_Device_Identification I've added kernel boot parameters as a means for rescue, in case this should cause regeression (I don't expect it will, but well...). The sg3_utils 1.48 update for factory is planned for week 41. Regards Martin --- End of quoted posts ---