What persistent device names are provided by the kernel in Red Hat Enterprise Linux 7, 8 or 9?

Solution Verified - Updated

Environment

  • Red Hat Enterprise Linux 9
  • Red Hat Enterprise Linux 8
  • Red Hat Enterprise Linux 7

Issue

  • How can static names be assigned for SCSI devices using udev in Red Hat Enterprise Linux 7, 8 or 9?

Resolution

While custom persistent SCSI device names can be created so there are persistent user defined names assigned to disks, there are already several persistent names that utilize symlinks provided by the kernel that should be considered. These symlinks are based upon self-identifiers: identification values tied to the disk or the data on disk. Regardless of which sdX name is assigned to a disk, these self-identifiers remain coupled to the physical disk or the data on the disk.
There are two types of self-identifiers: device based and data based.

  • Device based self-identifiers:
    Device identifiers are tied to a block device: for example, a disk identifier will not change across boots as they are based upon the device's self-identifiers (WWIDs, serial numbers). The WWID and serial number of a disk cannot be changed except by changing/replacing the disk -- the data is kept in the disk's firmware. Reformatting a filesystem or LVM use of the data contained within the device or partitioning changes will not affect these persistent identifiers.
    • World Wide Identifier (WWID) : /dev/disk/by-id
    • Serial number : /dev/disk/by-path
    • Examples of devfs entries available based upon device self-identifiers -- mostly WWID in these examples:
$ ls -l /dev/disk/by-id
lrwxrwxrwx 1 root root 11 Mar  1 14:20 dm-name-mpatha -> ../../dm-16
lrwxrwxrwx 1 root root 11 Mar  1 14:20 dm-uuid-mpath-3600140589a7ce21619947f5bcd95a91d -> ../../dm-16
lrwxrwxrwx 1 root root 11 Mar  8 11:38 scsi-3600140589a7ce21619947f5bcd95a91d -> ../../dm-16
lrwxrwxrwx 1 root root 11 Mar  8 11:38 wwn-0x600140589a7ce21619947f5bcd95a91d -> ../../dm-16

...or the individual paths of mpatha...

$ ls -l /dev/disk/by-path lrwxrwxrwx 1 root root 9 Mar 8 11:38 fc-0x2000d06726bc8a3c-0x21000024ff327b48-lun-9 -> ../../sdg
lrwxrwxrwx 1 root root 9 Mar 8 11:38 fc-0x2000d06726bc8a3c-0x21000024ff327b49-lun-8 -> ../../sdt
lrwxrwxrwx 1 root root 10 Mar 8 11:38 fc-0x2000d06726bc8a3d-0x21000024ff327b48-lun-9 -> ../../sdar
lrwxrwxrwx 1 root root 10 Mar 8 11:38 fc-0x2000d06726bc8a3d-0x21000024ff327b49-lun-8 -> ../../sdaf
lrwxrwxrwx 1 root root 9 Mar 8 11:38 pci-0000:5d:00.2-fc-0x21000024ff327b48-lun-9 -> ../../sdg
lrwxrwxrwx 1 root root 9 Mar 8 11:38 pci-0000:5d:00.2-fc-0x21000024ff327b49-lun-8 -> ../../sdt
lrwxrwxrwx 1 root root 10 Mar 8 11:38 pci-0000:5d:00.3-fc-0x21000024ff327b48-lun-9 -> ../../sdar
lrwxrwxrwx 1 root root 10 Mar 8 11:38 pci-0000:5d:00.3-fc-0x21000024ff327b49-lun-8 -> ../../sdaf

  • Data based self-identifiers:
    Data identifiers are tied to the data on disk: for example, a partition, filesystem or LVM UUID. These identifiers are stored within the data on-disk (partition data structures, filesystem metadata, LVM configuration data). Therefore these identifiers are not only tied to the data, but to the disk where this data resides. None of these values will change unless partitions are deleted/recreated, a new filesystem is created to replace an existing one, or LVM configuration changes the on-disk LVM metadata (recreate an logical volume for example).
    • Partition UUID : /dev/disk/by-partuuid
    • Unique identifier (UUID) : /dev/disk/by-uuid/
    • Label : /dev/disk/by-label/
    • Examples of devfs entries available based upon data self-identifiers -- mostly UUID in these examples:
$ ls -l /dev/disk/by-id
lrwxrwxrwx 1 root root 11 Mar  1 14:20 dm-uuid-mpath-uuid.44c782b4-4e72-4d9e-bc39-c7be0a409f22 -> ../../dm-18
lrwxrwxrwx 1 root root 11 Mar  1 14:20 scsi-uuid.44c782b4-4e72-4d9e-bc39-c7be0a409f22 -> ../../dm-18

...lvm uuid in /dev/disk/by-id/...

lrwxrwxrwx 1 root root 11 Mar 1 14:20 lvm-pv-uuid-xfmJzj-W2tc-ohi1-41BQ-fW8U-KIKS-5vTPJC -> ../../dm-17
lrwxrwxrwx 1 root root 10 Mar 8 11:38 lvm-pv-uuid-xYs6He-theA-upAb-9NUd-mtds-C558-tvcGuF -> ../../sdb2

$ ls -l /dev/disk/by-uuid lrwxrwxrwx 1 root root 11 Mar 8 11:38 a4cb696e-03bf-497e-959d-d0fdb229d642 -> ../../dm-18

  • In addition, many device mapper layered devices have defined names present within /dev/mapper that are persistent as they are based on WWID or UUIDs: for example using /dev/mapper/rhel-home in /etc/fstab
$ ls -l /dev/mapper/
lrwxrwxrwx 1 root root       8 Mar  1 14:20 mpatha -> ../dm-16
lrwxrwxrwx 1 root root       8 Mar  1 14:20 mpathb -> ../dm-17
lrwxrwxrwx 1 root root       8 Mar  1 14:20 mpathc -> ../dm-18
lrwxrwxrwx 1 root root       7 Mar  1 14:20 rhel-home -> ../dm-2
lrwxrwxrwx 1 root root       7 Mar  1 14:20 rhel-root -> ../dm-0
lrwxrwxrwx 1 root root       7 Mar  1 14:20 rhel-swap -> ../dm-1

Some file systems, such as logical volumes, span multiple disks. Red Hat recommends accessing these file systems using file system (LVM uuid) identifiers rather than disk identifiers.

[root@localhost-8-3-20 ~]# mount /dev/disk/by-uuid/154a330d-e2b7-4813-9690-735e71a23b67 /mnt/

[root@localhost-8-3-20 ~]# ll /dev/disk/by-uuid/ | grep sde
lrwxrwxrwx. 1 root root  9 Jan 29 09:36 154a330d-e2b7-4813-9690-735e71a23b67 -> ../../sde

[root@localhost-8-3-20 ~]# grep /mnt  /proc/self/mounts
/dev/sde /mnt xfs rw,seclabel,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0

Also see "System is failing to boot as 'sd' names for devices are changing". For example, instead of having /etc/fstab using a non-persistent sdX name:

/dev/sde                /test                   ext4    defaults        0 0

Change it to use the available kernel supplied persistent identifier /dev/disk/by-uuid based upon the filesystem UUID for mounting instead. So if the sdX order changes, the filesystem will still be found and mounted as expected:

$ ls -ls /dev/disk/by-uuid | grep sde
0 lrwxrwxrwx. 1 root root  9 Jan 26 09:35 38b02d2f-fcb5-486e-bf7e-d706c55e17ab -> ../../sde

/etc/fstab::
UUID=38b02d2f-fcb5-486e-bf7e-d706c55e17ab  /test                   ext4    defaults        0 
SBR
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.