<![CDATA[Dev1 Galaxy Forum / Disk blockdevice detecting order scrambled after every boot]]> http://dev1galaxy.org/viewtopic.php?id=5508 Tue, 31 Jan 2023 12:37:44 +0000 FluxBB <![CDATA[Re: Disk blockdevice detecting order scrambled after every boot]]> http://dev1galaxy.org/viewtopic.php?pid=40720#p40720 This is what realpath /sys/class/block/sd?/ gave back:

/sys/devices/pci0000:00/0000:00:11.0/ata1/host0/target0:0:0/0:0:0:0/block/sda
/sys/devices/pci0000:00/0000:00:11.0/ata2/host1/target1:0:0/1:0:0:0/block/sdb
/sys/devices/pci0000:00/0000:00:11.0/ata3/host2/target2:0:0/2:0:0:0/block/sdc
/sys/devices/pci0000:00/0000:00:11.0/ata4/host3/target3:0:0/3:0:0:0/block/sdd
/sys/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.0/host6/target6:0:0/6:0:0:0/block/sde
/sys/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.0/host6/target6:0:0/6:0:0:1/block/sdf
/sys/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.0/host6/target6:0:0/6:0:0:2/block/sdg
/sys/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.0/host6/target6:0:0/6:0:0:3/block/sdh

Note: When i've ran this command, the order was correct.

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 119,2G  0 disk 
└─sda1   8:1    0 119,2G  0 part /
sdb      8:16   0 119,2G  0 disk 
└─sdb1   8:17   0 119,2G  0 part 
sdc      8:32   0 465,8G  0 disk 
├─sdc1   8:33   0     8G  0 part [SWAP]
├─sdc3   8:35   0    64G  0 part 
├─sdc4   8:36   0 137,8G  0 part 
├─sdc5   8:37   0   128G  0 part 
└─sdc6   8:38   0   128G  0 part 
sdd      8:48   0 465,8G  0 disk 
├─sdd1   8:49   0     8G  0 part [SWAP]
├─sdd3   8:51   0    64G  0 part /media/GAMEDISK
├─sdd4   8:52   0 137,8G  0 part /media/WORKDISK
├─sdd5   8:53   0   128G  0 part /media/UTILDISK
└─sdd6   8:54   0   128G  0 part /media/SOFTDISK
sr0     11:0    1  1024M  0 rom  
sr1     11:1    1  1024M  0 rom

I suspect i need to compare this to that, when the order will be scrambled up.

ralph.ronnquist wrote:

The answer to why it turns up as a new thing for you would probably be that the kernel+module code involved has been updated to include a more refined multi-threading in one way or another.

That might be the reason.

ralph.ronnquist wrote:

Or, it might be hardware related that something has changed with some parts of the hardware due to aging, causing the startup timings to be slightly different now compared to how they have been previously.

That could be a reason, but why it only occurred after the update? Coincidence? Again? The other reason seems more likely.

ralph.ronnquist wrote:

I think we can agree to that magic is not involved.

It was never hypothesised at all.

]]> Tue, 31 Jan 2023 12:37:44 +0000 http://dev1galaxy.org/viewtopic.php?pid=40720#p40720 <![CDATA[Re: Disk blockdevice detecting order scrambled after every boot]]> http://dev1galaxy.org/viewtopic.php?pid=40711#p40711 To get an association table between PCI address and device node name, I think I might do:

ralph@stolpe:~$ realpath /sys/class/block/sd?/ 
/sys/devices/pci0000:00/0000:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block/sda
/sys/devices/pci0000:00/0000:00:1f.2/ata6/host5/target5:0:0/5:0:0:0/block/sdb
/sys/devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.1/2-1.1:1.0/host6/target6:0:0/6:0:0:0/block/sdc
/sys/devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.4/2-1.4:1.0/host7/target7:0:0/7:0:0:0/block/sdd
/sys/devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.2/2-1.2:1.0/host8/target8:0:0/8:0:0:0/block/sde

My example case shows 2 SATA disks and 3 USB disks. You may note that sdd and sde got enumerated in "wrong" order by the scsi module (relative to the USB host/port enumeration) for some reason. This appears to be consistent for that setup, but on occasion sdc and sdd are swapped, which is something I deal with by repeated monkey handson (= unplug+plugin) until order returns.

As @rolfie noted, the reason those "reorderings" happen is probably because the kernel+module code is multi-threaded with separate threads handling separate devices independently and these threads then compete and synchronize about "acquire the next device node name" on a first-come, first-served basis.

The answer to why it turns up as a new thing for you would probably be that the kernel+module code involved has been updated to include a more refined multi-threading in one way or another. Or, it might be hardware related that something has changed with some parts of the hardware due to aging, causing the startup timings to be slightly different now compared to how they have been previously. I think we can agree to that magic is not involved.

]]> Mon, 30 Jan 2023 22:37:20 +0000 http://dev1galaxy.org/viewtopic.php?pid=40711#p40711 <![CDATA[Re: Disk blockdevice detecting order scrambled after every boot]]> http://dev1galaxy.org/viewtopic.php?pid=40698#p40698 ralph.ronnquist wrote:

I would hope the PCI enumeration is the same, but I would also check rather than just guessing.
Though I suppose it doesn't matter any more.

How can i check this? lspci?

00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD9x0/RX980 Host Bridge (rev 02)
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD/ATI] RD890S/RD990 I/O Memory Management Unit (IOMMU)
00:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GFX port 0)
00:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 0)
00:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 1)
00:09.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 4)
00:0a.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 5)
00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] (rev 40)
00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller (rev 42)
00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) (rev 40)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 LPC host controller (rev 40)
00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to PCI Bridge (rev 40)
00:14.5 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI2 Controller
00:15.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB700/SB800/SB900 PCI to PCI bridge (PCIE port 0)
00:16.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:16.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 0
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 1
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 2
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 3
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 4
00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 5
01:00.0 VGA compatible controller: NVIDIA Corporation GM206 [GeForce GTX 960] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GM206 High Definition Audio Controller (rev a1)
02:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01)
03:00.0 Parallel controller: Oxford Semiconductor Ltd Device c110
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
05:00.0 Serial controller: Device 1c00:3250 (rev 10)
06:06.0 Serial controller: MosChip Semiconductor Technology Ltd. PCI 9865 Multi-I/O Controller
06:06.1 Serial controller: MosChip Semiconductor Technology Ltd. PCI 9865 Multi-I/O Controller
06:06.2 Parallel controller: MosChip Semiconductor Technology Ltd. PCI 9865 Multi-I/O Controller
06:07.0 Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1)
07:00.0 PCI bridge: Tundra Semiconductor Corp. Tsi381 PCIe to PCI Bridge (rev 02)
08:00.0 Multimedia audio controller: Creative Labs CA0108/CA10300 [Sound Blaster Audigy Series]

It does not shows the SATA disks separately, just the controller.

rolfie wrote:

Maybe I am wrong, but I think it is because the "enumeration" has been parallelised instead of looking at ata, then scsi, then usb in serial order. And since usb has become more important over the years chances are much higher nowadays that additional usb devices pop up as block devices.

Edith: Just checked, I already had issues with that when setting up my file server with Debian 3 Sarge. Adding/removing a scsi disk screwed the device naming, in my early Linux days I started to use uuid.

But all my disks are SATA (even the DVD drives) and they are unchanged for years.

]]> Mon, 30 Jan 2023 19:29:20 +0000 http://dev1galaxy.org/viewtopic.php?pid=40698#p40698 <![CDATA[Re: Disk blockdevice detecting order scrambled after every boot]]> http://dev1galaxy.org/viewtopic.php?pid=40690#p40690 Maybe I am wrong, but I think it is because the "enumeration" has been parallelised instead of looking at ata, then scsi, then usb in serial order. And since usb has become more important over the years chances are much higher nowadays that additional usb devices pop up as block devices.

Edith: Just checked, I already had issues with that when setting up my file server with Debian 3 Sarge. Adding/removing a scsi disk screwed the device naming, in my early Linux days I started to use uuid.

]]> Mon, 30 Jan 2023 11:45:09 +0000 http://dev1galaxy.org/viewtopic.php?pid=40690#p40690 <![CDATA[Re: Disk blockdevice detecting order scrambled after every boot]]> http://dev1galaxy.org/viewtopic.php?pid=40689#p40689 I would hope the PCI enumeration is the same, but I would also check rather than just guessing.
Though I suppose it doesn't matter any more.

]]> Mon, 30 Jan 2023 11:22:15 +0000 http://dev1galaxy.org/viewtopic.php?pid=40689#p40689 <![CDATA[Re: Disk blockdevice detecting order scrambled after every boot]]> http://dev1galaxy.org/viewtopic.php?pid=40687#p40687 But the PCI addresses should be the same as they are connected to the same slot, should not they?

Footnote: today "morning" (1:30-2:00 AM) i rewrote my backup script. Now it backups via the disklabels and i simply give the labels in a list, so the random order is no longer a concern.

Still, out of technological curiousity, i would like to know, why was it constant for 11 years and why it is random now.

]]> Mon, 30 Jan 2023 09:57:24 +0000 http://dev1galaxy.org/viewtopic.php?pid=40687#p40687 <![CDATA[Re: Disk blockdevice detecting order scrambled after every boot]]> http://dev1galaxy.org/viewtopic.php?pid=40683#p40683 I guess it would be kernel related since it's the kernel modules that invent the names.

Or, does the naming coincide with PCI numbering?
Eg that the PCI address for /dev/sda is lesser than the PCI address for /dev/sdb ?

]]> Mon, 30 Jan 2023 02:44:17 +0000 http://dev1galaxy.org/viewtopic.php?pid=40683#p40683 <![CDATA[Re: Disk blockdevice detecting order scrambled after every boot]]> http://dev1galaxy.org/viewtopic.php?pid=40681#p40681 What could cause that the order only started to be random after upgrading to Devuan 4?

]]> Sun, 29 Jan 2023 23:35:11 +0000 http://dev1galaxy.org/viewtopic.php?pid=40681#p40681 <![CDATA[Re: Disk blockdevice detecting order scrambled after every boot]]> http://dev1galaxy.org/viewtopic.php?pid=40678#p40678 Can only recommend to use UUIDs or labels, everything else is coincidence. Device detection order is ambiguous since a while already.

]]> Sun, 29 Jan 2023 20:22:22 +0000 http://dev1galaxy.org/viewtopic.php?pid=40678#p40678 <![CDATA[Re: Disk blockdevice detecting order scrambled after every boot]]> http://dev1galaxy.org/viewtopic.php?pid=40676#p40676 TCH wrote:

Well, the order was the same for 11 years, across several versions of several distributions, including Devuan. Is there a chance that this was only coincidence?

Yes, there's a chance it's coincidence. I've gotten away with using device names instead of uuids many times, even though the recommendation to use uuids in fstab goes back to some older version of debian that pre-dates devuan. I forget which one.  (squeeze? wheezy?)

]]> Sun, 29 Jan 2023 18:34:09 +0000 http://dev1galaxy.org/viewtopic.php?pid=40676#p40676 <![CDATA[Re: Disk blockdevice detecting order scrambled after every boot]]> http://dev1galaxy.org/viewtopic.php?pid=40673#p40673 Well, the order was the same for 11 years, across several versions of several distributions, including Devuan. Is there a chance that this was only coincidence?

]]> Sun, 29 Jan 2023 15:46:24 +0000 http://dev1galaxy.org/viewtopic.php?pid=40673#p40673 <![CDATA[Re: Disk blockdevice detecting order scrambled after every boot]]> http://dev1galaxy.org/viewtopic.php?pid=40672#p40672 PSA: I've already told the OP that this is the normal, expected behaviour (unless I'm wrong):

https://daemonforums.org/showthread.php?t=12340

]]> Sun, 29 Jan 2023 15:31:27 +0000 http://dev1galaxy.org/viewtopic.php?pid=40672#p40672 <![CDATA[Disk blockdevice detecting order scrambled after every boot]]> http://dev1galaxy.org/viewtopic.php?pid=40669#p40669 Hello there,

For the last 11 years, Ubuntu 10.04, Debian 7, Debian 8 and finally Devuan 2 all detected my disk devices in this order (save for Ubuntu, when i did not have the SSD-s yet, but the disk detecting order was constant there too):
/dev/sda: primary SSD where the system resides
/dev/sdb: secondary SSD where i back up the system with rsync regularly
/dev/sdc: secondary HDD where i back up the data with rsync regularly
/dev/sdd: primary HDD where the data resides
This order was constant, it never changed. This is the same order as the disks are plugged into the motherboard. (Yes, this is the same motherboard from 2012.) Clean, obvious, logical. Working.

A few days ago i've upgraded to Devuan 4 and now the order is entirely random. At every boot.
I tried to check how can i set up a persistent order, but all i found is how to write fstab entries by disk id; but this is not a partition problem, it is a disk blockdevice detecting order problem, it cannot be solved from fstab.

Any tips on this?

]]> Sun, 29 Jan 2023 14:54:24 +0000 http://dev1galaxy.org/viewtopic.php?pid=40669#p40669