[systemd-devel] Identical model scsi disks reported by scsi_id with identical ID_SERIAL

[Doug VanLeuven]

System under discussion:
centos 7 (Core) under hyper-V gen2, systemd-219-19.el7_2.12.x86_64
kernel 3.10.0-327.28.2.el7.x86_64 #1 SMP Wed Aug 3 11:11:39 UTC 2016

I bought two ID_VENDOR=HGST ID_MODEL=HMS5C4040BLE640
to create a mirror raid and using the default
     IMPORT{program}="scsi_id --export --whitelisted -d $devnode"
in /usr/lib/udev/rules.d they are both reported
as ID_SERIAL=SHGST_HMS5C4040BLE640

What ended up in /dev/disk/by-id was only
    scsi-SHGST_HMS5C4040BLE640 -> ../../sdb
and no link for sdc. Please notice ID_SERIAL is the same as ID_MODEL

This ID_SERIAL duplication gets logged in journal as:
Device dev-disk-by\x2did-scsi\x2dSHGST_HMS5C4040BLE640.device \
appeared twice with different sysfs paths \
/sys/devices/LNXSYSTM:00/device:00/ACPI0004:00/VMBUS:00/\
vmbus_8/host0/target0:0:0/0:0:0:2/block/sdb and \
/sys/devices/LNXSYSTM:00/device:00/ACPI0004:00/VMBUS:00/\
  vmbus_8/host0/target0:0:0/0:0:0:3/block/sdc

Mostly, when users have posted about seeing similar log messages to the
distribution lists, this is commented as a "harmless" message because
general practice has been to mount partitions using /dev/disk/by-uuid.
But I need whole disk reference for the raid.

/dev/sdb & /dev/sdc were created OK.
I could reference the drives that way, but since I was using them in a
mirror, I worried about a future fail, removal and replacement attach
getting the right physical devices as sdb & sdc. Like if I added
a hot spare I would be using the intel controller whereas
these drives were on the marvell controller. Maybe they end up
being assigned sdc & sdd with the spare at sdb.

By using SCSI page 0x83 instead of page 0x80 (which seems to be the
default) the drives report their true serial numbers
ID_SCSI_SERIAL=PL1331LAGY0HSH and ID_SCSI_SERIAL=PL1331LAGY0Z4H

By using:
IMPORT{program}="scsi_id --page=0x83 --export --whitelisted -d $devnode"
Then for the ID_SERIAL SYMLINK:
     ENV{ID_SCSI_SERIAL}!="?*", ENV{ID_SERIAL}=="?*"
and for the ID_SCSI_SERIAL SYMLINK
     ENV{ID_SCSI_SERIAL}=="?*"

This will stop the duplicate allocation and creates unique entries on
the drives with ID_SCSI_SERIAL and prior behavior for drives without.

But I understand that this would break existing installations.

For existing installations without disk ID_SERIAL duplicates, changing
the name from what appears to be the model number to a true serial
number would be a regression. There should to be a way to either:
1. alter the 1st & 2nd drives names only when the duplicate occurs
    on the 2nd drive
2. leave the 1st drive alone and use the different naming technique
    only for the 2nd drive after an "appeared twice" error because right
    now those drives don't have any name at all
The upside of 2 is existing implementations don't change, but the
downside is drive by-id names would change if the port sequence was
changed.

For my own purposes, I crafted a rules file in /etc/udev/rules.d that
creates entries in a new /dev/disk/by-serial/ to hold the links using
ID_SCSI_SERIAL and that works quite well for me. For example:
     zpool import -d /dev/disk/by-serial

True, I'm only using disk for raid that report ID_SCSI_SERIAL but
it does offer a way to introduce a different naming convention
without disturbing the existing conventions.

I could have used /dev/dev/by-path except path_id_compat has been
dropped from systemd-219-19 udev and IMPORT builtin 'path_id' returned
non-zero.
However openSUSE Leap 42.1 (x86_64) in a virtual machine under hyper-V
gen1 is still using udev-210-95.1.x86_64 and path_id_compat returns
ID_PATH_COMPAT=scsi-0:0:0:0 and correctly populates that directory.
I have to speculate why systemd dropped support for that, but
that is a different issue.

Hopefully this will kickstart some discussion
and someone else will have a better idea.