Does anyone know how the devices naming in linux work exactly?

[rado84]

Does anyone know how the devices naming in linux work exactly? I'm talking about the names you can get with blkid and the reason I'm asking is because it doesn't seem to work the way I thought it would. For instance, if you attach 2 SSDs to the SATA_1, SATA_3 and SATA_4 slots on the motherboard, logic suggests that they should appear as sda, sdc and sdd. However, this isn't the way the linux core presents them. It presents them as sda and sdb. I find that weird and is PROBABLY a glitch but I wanna be sure.
The thing is that not long ago I found one of my old hard drives and attached it to the motherboard. But then a few days ago I removed it from the computer (bc I wasn't using it anyway). Before I removed it the devices names were sdb, sda, sdd, sdc and sde - in that order. However, after I removed it, for an unknown reason they became sdc, sda1, sdd, sdf and sdb (again - in that order), so I had to rewrite fstab for them to be propely mounted at startup.
So, the questions are two:
• Do you know which module (I'm guessing it's a module in the linux kernel) is responsible for giving names to the devices?
• Shouldn't it name the devices after the slot of the motherboard they are attached to without changing the names?

 

[NorthWest]

rado84 wrote:

• Do you know which module (I'm guessing it's a module in the linux kernel) is responsible for giving names to the devices?
• Shouldn't it name the devices after the slot of the motherboard they are attached to without changing the names?

When the kernel boots, it can do different things on different boots for many reasons, one being that the probing that the kernel does to intialise disks is now executed within a parallel (or near parallel) processing framework so there's a degree of arbitrariness in the device names depending on which disk is probed first. For some more explanation, perhaps have a look at:

Chapter 6. Overview of persistent naming attributes Red Hat Enterprise Linux 8 | Red Hat Customer Portal

Access Red Hat’s knowledge, guidance, and support through your subscription.

access.redhat.com

To alleviate the problem, disks can be named by UUID (as found in /dev/disk/), and usually are named that way in the fstab file by default now in the major current distributions that I'm familiar with like debian and fedora. You can alternatively use a label you create. The disk probing software is not like a normal module, rather it's a core part of the kernel. No doubt it's hackable, with the right skill set.

 

[saar2u]

Special device files are used by kernel drivers to control a device. There can be more than one special device file that maps to the same physical device. For example, in a multipath environment with four paths to the same device, four different device files will map to the same physical device.
The device files are located in the /dev directory and are addressed by a major and minor number pair. Fibre Channel attached devices are managed as SCSI disk devices by the sd driver. Thus, each of the attached storage unit LUNs has a special device file in the Linux directory /dev.
SCSI disk devices have special device files that start with an ‘sd’ prefix, and have the following naming format:

• /dev/sd[a-z][a-z][1-15]

Names without a trailing digit refer to the whole disk, while names with a trailing digit refer to a partition of that whole disk. By convention, SCSI disks have a maximum of 16 minor numbers mapped to a single disk. Thus, for each whole disk, there is a maximum of 15 partitions per disk because one minor number is used to describe the entire disk (for example /dev/sda), and the other 15 minor numbers are used to refer to partitions for that disk (for example /dev/sda1, /dev/sda2, etc). The following example displays the device files for the whole disk /dev/sda, which has a major number of 8 and a minor number of 0, and its 15 partitions.

Note: If the server is running DM Multipath, these SCSI disk devices would not normally be accessed. Use the corresponding multipath device under /dev/mapper/ instead.

For Red Hat, the kernel automatically creates the device files for 128 devices. For SUSE, there are only special device files for the first 16 disks. You must create the device files for additional disks by using the mknod command. For 2.6 kernels, the special device files are only created when they are detected and recognized by the kernel. The /proc/partitions file lists all the ‘sd’ devices that are recognized by the SCSI disk driver, including the sd name, major number, minor number, and size of each disk device.

The following is an example /proc/partitions file:

 

[flavio]

I use to allow just root (/), /home, EFI and Swap partitions in fstab, and always using UUID to identify them. So, fstab will mount them correctly, even if sdb becomes sdc, or something else.

For all other partitions, I prefer to let udisks2 to mount them automatically. I just label them as, e.g., Sites, Works, Linux2, Linux3, Home2, Home3..., so udisks2 mounts them as "Sites", "Works", and so on -- no matters if they are "sdb5" or "sdc10".

Only in Debian, I could not udisks2, so I had to let fstab to mount all additional partitions. -- I have used Disk Manager to edit fstab, and used Labels for them:

UUID=7A0B-66EE                             /boot/efi  vfat    defaults,noatime               0  2
UUID=fc576ba0-2fd4-483b-b090-55d295f1dccf  /          ext4    defaults,noatime,discard       0  1
UUID=1eb92b4b-f8d8-4620-8aaf-df815197143a  /home      ext4    defaults,noatime               0  2
UUID=a6bc03e6-ae71-4504-a8f5-c7bc79021e96  none          swap    sw                             0  0
tmpfs                                      /tmp           tmpfs   defaults,noatime,mode=1777 0  0
LABEL=Warehouse  /media/Warehouse   ext4        defaults,user    0   2
LABEL=Depot1     /media/Depot1      ext4        defaults,user    0   2
LABEL=Sites      /media/Sites       ext4        defaults,user    0   0
LABEL=Works      /media/Works       ext4        defaults,user    0   0
LABEL=Linux1     /media/Linux1      btrfs       defaults,user    0   0
LABEL=Linux2     /media/Linux2      ext4        defaults,user    0   0
# LABEL=Linux3     /media/Linux3      ext4        defaults,user    0   0
LABEL=Linux4     /media/Linux4      ext4        defaults,user    0   0
LABEL=Linux5     /media/Linux5      ext4        defaults,user    0   0
LABEL=Linux6     /media/Linux6      ext4        defaults,user    0   0
LABEL=Linux7     /media/Linux7      ext4        defaults,user    0   0
LABEL=Linux8     /media/Linux8      ext4        defaults,user    0   0
LABEL=Linux9     /media/Linux9      ext4        defaults,user    0   0
LABEL=Linux10    /media/Linux10     ext4        defaults,user    0   0
LABEL=Linux11    /media/Linux11     ext4        defaults,user    0   0
LABEL=Linux12    /media/Linux12     ext4        defaults,user    0   0
LABEL=Home1      /media/Home1       xfs         defaults,user    0   0
LABEL=Home2      /media/Home2       ext4        defaults,user    0   0
# LABEL=Home3      /media/Home3       ext4        defaults,user    0   0
LABEL=Home4      /media/Home4       ext4        defaults,user    0   0
LABEL=Home5      /media/Home5       ext4        defaults,user    0   0
LABEL=Home6      /media/Home6       ext4        defaults,user    0   0
LABEL=Home7      /media/Home7       ext4        defaults,user    0   0
LABEL=Home8      /media/Home8       ext4        defaults,user    0   0
LABEL=Home9      /media/Home9       ext4        defaults,user    0   0
LABEL=Home10     /media/Home10      ext4        defaults,user    0   0
LABEL=Home11     /media/Home11      ext4        defaults,user    0   0
LABEL=Home12     /media/Home12      ext4        defaults,user    0   0

 

[dos2unix]

device paths change. uuids don't.
Most distro's recommend you use the UUID in fstab instead of the device path.

UUID=7692b8e9-bc49-486f-91b5-37765a526737 /home xfs defaults 0 0

To get the uuid, you usually have to run this as root.

sudo blkid
or
sudo blkid /dev/sda2 (whatever your device path is currently, that you want to mount)

 

[digitaltrails]

Does anyone know how the devices naming in linux work exactly? I'm talking about the names you can get with blkid and the reason I'm asking is because it doesn't seem to work the way I thought it would. For instance, if you attach 2 SSDs to the SATA_1, SATA_3 and SATA_4 slots on the motherboard, logic suggests that they should appear as sda, sdc and sdd. However, this isn't the way the linux core presents them. It presents them as sda and sdb. I find that weird and is PROBABLY a glitch but I wanna be sure.

That is weird, I've not experienced that, I wonder if the motherboard is configured to create a RAID-0 virtual drive of a couple of the SATA slots?

The thing is that not long ago I found one of my old hard drives and attached it to the motherboard. But then a few days ago I removed it from the computer (bc I wasn't using it anyway). Before I removed it the devices names were sdb, sda, sdd, sdc and sde - in that order. However, after I removed it, for an unknown reason they became sdc, sda1, sdd, sdf and sdb (again - in that order), so I had to rewrite fstab for them to be propely mounted at startup.
So, the questions are two:
• Do you know which module (I'm guessing it's a module in the linux kernel) is responsible for giving names to the devices?
• Shouldn't it name the devices after the slot of the motherboard they are attached to without changing the names?

The order in which drives are recognised can change depending on boot-time race-conditions in the kernel and/or motherboard weirdness. On my own system they seem pretty consistent, but I believe that's not always the case, I think they did once change around after some major kernel/distro change (but I've been on OpenSUSE for more than a decade so it's hard to remember).

The UUID's can be relied on to remain constant.

For my desktop I prefer to use file system labels (e2label or whatever is available for the filesystem in use). That what I can swap drives or introduce new drives and do not need to touch the fstab.

The actual "linux device naming conventions" are easily found using google.

 

[dos2unix]

You can write your own udev-rules, if you want to make them persistant.

https://linuxconfig.org/tutorial-on-how-to-write-basic-udev-rules-in-linux