[systemd-devel] Identical model scsi disks reported by scsi_id with identical ID_SERIAL
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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Identical model scsi disks reported by scsi_id with identical ID_SERIAL
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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel