I have observed that between repeated boots of the same system, the mapping between the device names /dev/sda, /dev/sdb/... and the physical hard drives stays the same.
However I am not sure if it remains the same if I plug the hard drives into different sockets on the motherboard or if I add/remove drives.
What guarantees does Linux make regarding the mapping of device names to the physical hard drives?
Which rules does it use to map physical hard drives to files in /dev/?
The drive names are (on a typical Linux system) decided by the kernel (as the device must first be detected there), and may later be modified by udev. How it decides which hardware maps to which block special file is an implementation detail that will depend your udev configuration, kernel configuration, module setup, and many other things, too (including plain luck).
The mapping of a device to a drive letter is not guaranteed to always be the same even with the same hardware and configuration (there are some systems which are particularly prone to swapping around device names due to race conditions, like those in parallel module loading).
To answer the question you didn't ask, don't use /dev/sd* as an identifier for anything unless you are sure about the device you're mounting beforehand (for example, you are manually mounting after checking with fdisk and/or blkid). Instead, use filesystem labels, filesystem UUIDs, or disk IDs to ensure you are pointing to the correct device, partition, or filesystem by its properties, instead of its detection order. You can find the disk IDs in /dev/disk/by-id, which is a convienient place to mount from, and guarantees that you're always using the same disk.
To find which disk IDs you can use for the partition currently on /dev/sda1, for example, you can use find:
$ find -L /dev/disk/by-id -samefile /dev/sda1
/dev/disk/by-id/wwn-0x5000cca22dd9fc29-part1
/dev/disk/by-id/ata-HGST_HUS724020ALA640_PN1181P6HV51ZW-part1
Related question (from the auto sidebar): How to prevent /sda /sdb changes between boots?
It guarantees to assign them in the order they are "probed" (or "bound") by the kernel.
Greg KH advocates not relying on this order. He likes give an example of a (real!) hideously designed motherboard, which re-arranges the PCI order between subsequent boots. It sounds like the above question is about one such example.
Loadable modules are loaded by userspace. udev is parallelized using multiple processes, and does not guarantee to load modules in any particular order. Parallelizing initialization like this can have real performance benefits, as the module initialization functions may run in parallel, and these functions can include lengthy delays waiting for hardware.
Currently, it is possible to assume that the kernel default is to probe built-in drivers synchronously, and hence in a deterministic order.
As of v4.2 the Linux kernel now sports asynchronous probe support
(apparently this feature is used by Google Chrome OS).
https://www.do-not-panic.com/2015/12/linux-asynchronous-probe.html
https://kernelnewbies.org/Linux_4.2#Core
Based on historic messages you might also have assumed that there is scepticism / fatigue about such efforts, not least from Linus. Based on the above, it seems that whatever enhanced scrutiny and/or raging shouty messages have not stood in the way of merging this option.
Enabling it kernel-wide is another matter, since "[some] drivers do not work well with asynchronous probing because of driver bug or not optimal driver organization". Maybe Linus did not blow up (?) at the merged commit message which says "the end goal is to make the probing asynchronous by default", but that is only one opinion, and it doesn't tell us how well it has progressed since v4.2.
sd• devices for the same media when it plugs in after absence (often long). Ī̲’ll give the author some time to fix the stuff, i.e. to add necessary information about user-space programs (such as udevd(8)) that intervene to kernel’s device management.
– Incnis Mrsi
Mar 18 '21 at 10:29
I have an external USB drive, which I mount by label, so it always mounts when fstab runs, however, I still have problems. Sometimes the drive assignment will change even with the device mounted, and files on the changed drive become inaccessible.
I'm running Ubuntu 16.04.4 LTS (Linux 4.4.0-128-generic i686).
I use sleep mode between daily sessions, and I suspect the drive gets reassigned when waking from sleep mode, although I'm not absolutely sure about this. Typically it is assigned /dev/sdc, and I have a USB SD card reader which I leave plugged in, which is assigned /dev/sdd. There are times when I'm not able to read from or write to the external drive. When this happens, I find it has been reassigned to /dev/sde. One fix is to simply reboot the OS, and everything comes back happy, but I'm looking for a fix where I don't need to go to that extreme.
I found a better fix is to first close any applications which are accessing any partition on the external drive, including any terminal tabs that are on a folder on a partition on the external drive. If I have an application where I made changes to a file which is on the inaccessible drive, it is necessary to save the file to another, accessible partition, for two reasons: 1) so the data is saved, and 2) to break the link to the inaccessible partition. Then I unmount the partition(s) with
sudo umount /dev/sde
or whatever assignment for all partitions of the external drive. Then I remount all partition(s) with
sudo mount -a
Once I do this, I find the errant partition is now accessible again by any application, even if the partition is still assigned /dev/sde instead of the expected /dev/sdc. As fstab works with labels and mounts these partitions to folders, this reassignment is not an issue. I seem to have to do this two or three times a month.
I'm wondering, even though I use labels for partition identification, if mount maps the label to the device letter assignment, which is what is causing this problem. I can't say for sure... just pondering.
dmesg command). I would say this is not really related to the original question... except that suspend with USB might be a special case. (Also MMC i.e. sd card and some others).
– sourcejedi
Jul 29 '18 at 14:40
What guarantees does Linux make regarding the mapping of device names to the physical hard drives?
Which rules does it use to map physical hard drives to files in /dev/?
I cannot speak for every linux distribution but I can speak for how SUSE does it, in SUSE there is available these options
mount by
by device name I will say is bad because it causes linux to check the hardware and the order in which it sees drives connected is how it does the mapping to sda, sdb, and so on. So if your boot device and partition is called out as sda and you simply switch the order of drives in removable slots (on a server) or switch the sata cables in a home computer between two drives it will upset things. Also my experience has been (on servers with 8, 16, or 24 drive bays) that it often goes backwards that drive slot 0 does NOT map to sda... if you had 3 drives then slot 2 is sda, slot 1 sdb, and slot 0 sdc. AND add any temporary hardware that gets mapped as /dev/sda and pushes the drives down a letter upsetting things. But I will say this method is good when setting up a gold image operating system drive that you plan to clone... you don't have to worry about hard drive id's or WWN's changing on a new disk a least for a little while... if it is the only disk in system it is likely that it will always show up as sda.
FSTAB syntax:**
/dev/sdc2 / EXT3 acl,user_xattr 1 1
/dev/sdc1 /boot/efi VFAT
/dev/sdb1 /data XFS defaults 1 0
by device id is what I always use because it solves basically all the problems mentioned for "by device name", and it has worked well for me over the years which just about everything. Once mounting is configured by device id the drives just need to be present or connected. If drives get moved around or new hardware gets mapped as some /dev/sd? it does not affect anything that was previously configured.
FSTAB syntax:
/dev/disk/by-id/scsi-35000aab12345a30-part2 / EXT3 acl,user_xattr 1 1
/dev/disk/by-id/scsi-35000aab12345a30-part1 /boot/efi VFAT
/dev/disk/by-id/scsi-3600404abc123def456-part1 /data XFS defaults 1 0
by UUID {universally unique identifier} I think is also a good one, it works much like "by device-id" however I do not know how the UUID is created and made unique, or if it ends up being the same as by device id?
by volume label can also work well provided you or someone has made a good volume label to whatever filesystem or partition or volume that is to be mounted. I am sure it would be problematic if two partitions had the same volume label, such as "boot" for example I suspect whichever volume lablel linux finds first is the one it would use if it does not report duplicate volume labels.
Also, this is all based on linux Udev (to sort of answer which algorithm is used). I believe it is the same from older Init linux as well as on the newer Systemd linux, since Udev is the package used in most all linux distributions. And I think it is mostly the syntax in /etc/fstab specifically the first field or column on each line is what determines the mount method that will happen (not algorithm), that there is not some other config file somewhere and I say this because you can have multiple lines in /etc/fstab each mounting something different by a different mount method (by name, id, uuid, or label) and as far as I know nothing else anywhere has changed except for the syntax in the fstab file.
alias list_disks='find /dev/disk/by-id/ -iname ata-* -o -iname usb-* -o -iname dm-name* | grep -v -- -part | while read disk ; do echo $(basename $(readlink $disk)) $(basename $disk); done | sed -re "s/(usb|ata)-// ; s/(SATA|Generic)_//" | sort'– cas May 06 '16 at 04:56/dev/sd*? – Konstantin Schubert May 06 '16 at 04:59searchcommand to find the device with correct UUID. – sourcejedi Jul 29 '18 at 08:23