by-path persistent device names overlap the 2nd 4-port section of the controller on top of the first: pci-0000:03:00.0-sas-0x500304800e246e00-lun-0 -> ../../sdc pci-0000:03:00.0-sas-0x500304800e246e00-lun-0-part1 -> ../../sdc1 pci-0000:03:00.0-sas-0x500304800e246e01-lun-0 -> ../../sdd pci-0000:03:00.0-sas-0x500304800e246e01-lun-0-part1 -> ../../sdd1 pci-0000:03:00.0-sas-0x500304800e246e01-lun-0-part2 -> ../../sdg2 pci-0000:03:00.0-sas-0x500304800e246e02-lun-0 -> ../../sde pci-0000:03:00.0-sas-0x500304800e246e02-lun-0-part1 -> ../../sde1 sd[c-e] are on ports 6:0-3 and sd[ge] are on ports 7:0-1 where 6 is the first half and 7 is the second half of the "dual" hardware config /devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:08.0/0000:03:00.0/host6/port-6:1/end_device-6:1/target6:0:1/6:0:1:0/block/sdd /devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:08.0/0000:03:00.0/host7/port-7:1/end_device-7:1/target7:0:1/7:0:1:0/block/sdg E: DEVLINKS=/dev/disk/by-id/ata-M4-CT128M4SSD2_00000000113003152D83 /dev/disk/by-id/wwn-0x500a075103152d83 /dev/disk/by-path/pci-0000:03:00.0-sas-0x500304800e246e01-lun-0 E: DEVLINKS=/dev/disk/by-id/ata-WD_WD30EFRX-68AX9N0_WD-WMC1T1636965 /dev/disk/by-id/wwn-0x50014ee0ae28a327 /dev/disk/by-path/pci-0000:03:00.0-sas-0x500304800e246e01-lun-0 Whatever is determining ID_PATH isn't doing it right in this case. Let me know what additional information I can provide.
Please report this to http://bugs.freedesktop.org/enter_bug.cgi?product=systemd and leave unnecessary information like what init system is being used out from it to avoid confusion
If you care to track or this ends up as a search result, bug filed: https://bugs.freedesktop.org/show_bug.cgi?id=63806
Can you please test with udev-203 and let us know the results? Thanks, William
is udevadm trigger sufficient to repop the path?
(In reply to comment #4) > is udevadm trigger sufficient to repop the path? Results of the above command: pci-0000:03:00.0-sas-0x500304800e246e00-lun-0 -> ../../sdf pci-0000:03:00.0-sas-0x500304800e246e00-lun-0-part1 -> ../../sdc1 pci-0000:03:00.0-sas-0x500304800e246e01-lun-0 -> ../../sdg pci-0000:03:00.0-sas-0x500304800e246e01-lun-0-part1 -> ../../sdg1 pci-0000:03:00.0-sas-0x500304800e246e01-lun-0-part2 -> ../../sdg2 pci-0000:03:00.0-sas-0x500304800e246e02-lun-0 -> ../../sde pci-0000:03:00.0-sas-0x500304800e246e02-lun-0-part1 -> ../../sde1 So this time around the 2nd half successfully clobbered the first half links.
http://bugs.freedesktop.org/show_bug.cgi?id=63806#c1 Keywords: NeedPatch :-/
Like Kay pointed out at http://bugs.freedesktop.org/show_bug.cgi?id=63806#c1, nobody is at position of fixing this without said hardware There is always the possibility of getting this fixed through donation of SAS software to upstream systemd (udev) developers I'm sure someone is willing to accept free hardware in exchange for some code :-)
Did the pre-183 udev have any issues with this type of thing in this particular hardware? I know that the old method for mapping storage was deprecated long ago, but if there is enough of a "need" for it, eudev could always bring it back under a legacy USE flag...
I did not have this hardware prior to 183 and as it's in production I will not have the opportunity to test.
This will be fixed in udev-218 by the following commit: http://cgit.freedesktop.org/systemd/systemd/commit/?id=66bba0e701b95dc42ed53e8f0799a7e2b944c147 There is no interest in backporting this patch because it makes a very significant change to the naming scheme, so you will need to wait for 218 or apply the patch manually.
