After switching to sys-kernel/gentoo-kernel-bin-6.6.74 /dev/disk/by-path only contains one of the disks connected to my storage controller. In 6.6.67 and previous kernels for the last one or two years I've had the following entries in /dev/disk/by-path: pci-0000:b1:00.0-sas-0x31402ec014a80020-lun-0 pci-0000:b1:00.0-sas-0x31402ec014a80021-lun-0 pci-0000:b1:00.0-sas-0x31402ec014a80022-lun-0 pci-0000:b1:00.0-sas-0x31402ec014a80023-lun-0 pci-0000:b1:00.0-sas-0x31402ec014a80024-lun-0 pci-0000:b1:00.0-sas-0x31402ec014a80025-lun-0 pci-0000:b1:00.0-sas-0x31402ec014a80026-lun-0 pci-0000:b1:00.0-sas-0x31402ec014a80027-lun-0 After upgrading to 6.6.74 I only have this: pci-0000:b1:00.0-sas-phy0-lun-0 Also, the corresponding partitions actually points to partitions on different disks, and it seems to be random each boot: pci-0000:b1:00.0-sas-phy0-lun-0-part1 -> ../../sdc1 pci-0000:b1:00.0-sas-phy0-lun-0-part2 -> ../../sda2 pci-0000:b1:00.0-sas-phy0-lun-0-part9 -> ../../sdi9 It looks like the unique hex-value that previously differentiated the disks in this location has been changed to "phy0", making all disks have the same symlink which obviously is impossible so only one link remains. For me the problem is mostly mundane as it only caused smartd to fail on invalid configuration, but I think there could be more dangerous scenarios Reproducible: Always Steps to Reproduce: 1. Check symlinks in /dev/disk/by-path when running <gentoo-kernel-bin-6.6.74 2. Boot with gentoo-kernel-bin-6.6.74 3. Compare symlinks in /dev/disk/by-path Actual Results: symlinks differs Expected Results: symlinks should be the same I've only tested one machine, using this controller: b1:00.0 Serial Attached SCSI controller: Adaptec Smart Storage PQI SAS (rev 01) DeviceName: Embedded RAID 1 Subsystem: Hewlett-Packard Company Smart Array P408i-a SR Gen10 Kernel driver in use: smartpqi Kernel modules: smartpqi
It would be helpful if you could bisect this to a specific kernel commit.
This is as far as I got (I'm not a developer): First of, the "sas-phy0"-links seems to be present even on 6.6.67, and behaves just the same, so the issue is only the missing "sas-0x"-links. I have only seen this problem on this controller (but it's also the only sas controller I have). I think I managed to trace the name generation for the "sas-0x" links to the function handle_scsi_sas_wide_port in systemd-udev. [0] This function is only called from one place as far as I can tell, and the commit that last touched the condition for it explicitly mentions the smartpqi driver (which is used for my controller) doing something unexpected. I don't know if this is relevant or not. [1] This is not a systemd/udev issue since booting 6.6.67 on the same systemd version properly populates the links (systemd version is 256.10 for the record). Unfortunately it doesn't look like the smartpqi driver has been touched between 6.6.67 and 6.6.74. Latest commit is listed for 2024-10-10 which is over two months before 6.6.67 was released. [2] So the only conclusion I can give you is that it's probably not caused by a direct change to the smartpqi driver... [0] https://github.com/systemd/systemd/blob/v256.10/src/udev/udev-builtin-path_id.c#L154 [1] https://github.com/systemd/systemd/commit/7f6674624eedc95db2a9877edc6ff424f4453531 [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/scsi/smartpqi?h=linux-6.6.y
