Chapter 2. Persistent naming attributes


The way you identify and manage storage devices ensures the stability and predictability of the system. RHEL 9 uses two primary naming schemes for this purpose: traditional device names and persistent naming attributes.

Traditional device names

The Linux kernel assigns traditional device names based on the order in which they appear in the system or their enumeration. For example, the first SATA drive is usually labeled as /dev/sda, the second as /dev/sdb, and so on. While these names are straightforward, they are subject to change when devices are added or removed, the hardware configuration is modified, or the system is rebooted. This can pose challenges for scripting and configuration files. Furthermore, traditional names lack descriptive information about the purpose or characteristics of the device.

Persistent naming attributes

Persistent naming attributes (PNAs) are based on unique characteristics of the storage devices, making them more stable and predictable when presented to the system, even across system reboots. One of the key benefits of PNAs is their resilience to changes in hardware configurations, making them ideal for maintaining consistent naming conventions. When using PNAs, you can reference storage devices within scripts, configuration files, and management tools without concerns about unexpected name changes. Additionally, PNAs often include valuable metadata, such as device type or manufacturer information like combination of vendor, model name, and serial number, enhancing their descriptiveness for effective device identification and management. PNAs are eventually used to create device links in /dev/disk directory to access individual devices. The way the device link names are constructed and managed is driven by udev rules.

The following is a list of directories we can find in /dev/disk/:

  • Directories with content that remain unique even after system restart:

    • by-id: based on hardware attributes, with the vendor/model/serial_string combination.
    • by-path*: Based on physical hardware placement. For devices or disks physically attached to a machine, this is the slot or port where they are connected physically to the host bus on the motherboard. However, for devices or disks attached over a network, this contains the network address specification.
    • by-partlabel: Based on a label assigned to a device partition. These labels are assigned by the user.
    • by-partuuid: Based on a unique number in the form of UUID that is auto-generated.
    • by-uuid: Based on a unique number in the form of UUID that is autogenerated.
  • Directory with content that remain unique during the current system run, but not after system restart:

    • by-diskseq: diskseq` is 'disk sequence number' that starts at 1 when the system boots. It assigns this number to a newly attached disk and each one after that gets the next number in sequence. When the system reboots, the counter restarts at 1.
  • Directories with content that are used specifically for loop devices:

    • by-loop-ref
    • by-loop-inode

2.1. Persistent attributes for identifying file systems and block devices

In RHEL 9 storage, persistent naming attributes (PNAs) are mechanisms that provide components for consistent and reliable naming for storage devices across system reboots, hardware changes, or other events. These attributes are used to identify storage devices consistently, even if the storage devices are added, removed, or reconfigured.

PNAs are used to identify both file systems and block devices, but they serve different purposes:

Persistent attributes for identifying file systems
  • Universally unique identifier (UUID)

    UUIDs are primarily used to uniquely identify file systems on storage devices. Each file system instance has its own UUID assigned automatically, and this identifier remains constant even if the file system is unmounted, remounted, or the device is detached and reattached.

  • Label

    Labels are user-assigned names for file systems. While they can be used to identify and reference file systems, they are not as standardized as UUIDs. Since a user assigns the file system label, its uniqueness depends on their choice. Labels are often used as alternatives to UUIDs to specify file systems in configuration files.

    When you assign a label to a file system, it becomes part of the file system metadata. This label remains associated with the file system even if it is unmounted, remounted, or the device is detached and reattached.

Persistent attributes for identifying block devices
  • Universally unique identifier (UUID)

    UUIDs can be used to identify storage block devices. When a storage device is formatted, a UUID is often assigned to the device itself. Such UUIDs are usually generated and assigned to virtual block devices layered on top of other block devices, where the real devices are at the bottom level. For example, device-mapper (DM) based devices and their related subsystems, such as Logical Volume Manager (LVM) and crypt, use UUIDs for device identification, such as Logical Volume UUID (LVUUID) and crypt UUID.

    Also, multiple-device (MD) based devices have UUIDs assigned. The virtual devices usually also mark the underlying devices with component UUIDs. For example, LVM marks its underlying devices with a Physical Volume UUID (PVUUID) and MD marks its underlying devices with an MD component UUID.

    These UUIDs are embedded within the virtual block device metadata and they are used as persistent naming attributes. It allows you to uniquely identify the block device, even if you change the file system that resides on it. UUIDs are also assigned for device partitions.

    Such UUIDs can coexist with other device IDs. For example, an sda device at the bottom of the device stack which is identified by its vendor/model/serial_number combination or WWID, can also have a PVUUID assigned by LVM. This is then recognized by LVM itself to build up the Volume Group (VG) or Logical Volume (LV) in a layer above it.

  • Label or Name Labels or names can be assigned to certain block devices too. This applies to partitions which can have user-assigned labels. Some of the virtual block devices, like device-mapper (DM) based devices and multiple-device (MD) based devices also use names to identify devices.
  • World Wide Identifier (WWID)

    WWID encompasses a family of identifiers which are globally unique and they are associated with storage block devices or storage components in general. They are commonly used in enterprise-level Storage Area Networks (SANs), like Fibre Channel (FC), to identify a storage node - World Wide Node Name (WWNN) or actual port/connection to a storage device on the node - World Wide Port Name (WWPN). WWIDs ensure consistent communication between servers and SAN storage devices and help manage redundant paths to storage devices.

    Other types of devices may use a form of WWIDs too, like NVME devices. These devices do not necessarily need to be accessed over a network or SAN, and they do not have to be enterprise-level devices either.

    The WWID format does not follow a single standard. For example, SCSI uses formats such as NAA, T10, and EUI. The NVME uses formats such as EUI-64, NGUUID, and UUID.

  • Serial string

    The serial string is a unique string identifier assigned to each storage block device by the manufacturer. It can be used to differentiate among storage devices and may be used in combination with other attributes like UUIDs or WWIDs for device management.

    Within udev rules, and consequently in the /dev/disk/by-id content, the 'short serial string' typically represents the actual serial string as reported by the device itself. Whereas, 'serial string' is composed of several components, usually <bus_type>-<vendor_name>_<model_name>_<short_serial_string>.

    WWIDs and serial strings are preferred for real devices. For virtual devices, UUIDs or names is preferred.

2.2. udev device naming rules

Userspace device manager (udev) subsystem allows you to define rules for assigning persistent names to devices. These rules are stored in a file with a .rules extension. There are two primary locations for storing the udev rules:

  • /usr/lib/udev/rules.d/ directory contains default rules that come with an installed package.
  • /etc/udev/rules.d directory is intended for custom udev rules.
Note

If a rule from /usr/lib/udev/rules.d/ is modified, it will be overwritten by the rules file of the package during an update. Hence, any manual or custom rule should be added in /etc/udev/rules.d where it is retained until removed explicitly. Before use, udev rules from both directories are merged. If a rule in /etc/udev/rules.d has the same name as one in /usr/lib/udev/rules.d/ the one in the former takes precedence.

The purpose of these rules is to ensure that storage devices are consistently and predictably identified, even across system reboots and configuration changes.

udev rules define actions to execute based on incoming events that notify about adding, changing or removing a device. This also helps to collect values for the persistent storage attributes and direct udev to create the /dev content based on the collected information. The udev rules are written in human-readable format using key-value pairs.

In the case of storage devices, udev rules control creation of symbolic links in the /dev/disk/ directory. These symbolic links provide user-friendly aliases for storage devices, making it more convenient to refer to and manage these devices.

You can create custom udev rules to specify how devices should be named based on various attributes such as serial numbers, World Wide Name (WWN) identifiers, or other device-specific characteristics. By defining specific naming rules, you have precise control over how devices are identified within the system. To create a specific custom symbolic link in /dev for a device see the udev(7) man page on your system.

While udev rules are very flexible, it is important to be aware of udev limitations:

  • Accessibility Timing: Some storage devices might not be accessible at the time of a udev query.
  • Event-Based Processing: The kernel can send udev events at any time, potentially triggering rule processing and link removal if a device is inaccessible.
  • Processing Delay: There might be a delay between event generation and processing, especially with numerous devices, causing a lag between kernel detection and link availability.
  • Device Accessibility: External programs invoked by udev rules, like blkid, might briefly open the device, making it temporarily inaccessible for other tasks.
  • Link Updates: Device names managed by udev in /dev/disk/ can change between major releases, requiring link updates.

The following table lists the symlinks available in /dev/disk.

Device typeNonpersistent Name (Kernel Name)Persistent Symlink Names

Real Devices

nvme (Non-Volatile Memory Express)

/dev/nvme*

/dev/disk/by-id/nvme-<wwid>
/dev/disk/by-id/nvme-<model>_<serial>_<nsid>

scsi (Small Computer System Interface)

/dev/sd*, /dev/sr*

/dev/disk/by-id/scsi-<model>_<serial>
/dev/disk/by-id/wwn-<wwn>
/dev/disk/by-id/usb-<vendor>_<model>_<serial>-<instance>
/dev/disk/by-id/ieee1394-<ieee1394_id>
/dev/disk/by-path/ip-<ip_address>:<ip_port>-iscsi-<iqn_name>-lun-<lun_number>
/dev/disk/by-id/scsi-0<vendor>_<model>_<id>
/dev/disk/by-id/scsi-1<t10_vendor_id>
/dev/disk/by-id/scsi-2<eui64_id>
/dev/disk/by-id/scsi-3<naa_regext_id>
/dev/disk/by-id/scsi-3<naa_reg_id>
/dev/disk/by-id/scsi-3<naa_ext_id>
/dev/disk/by-id/scsi-3<naa_local_id>
/dev/disk/by-id/scsi-8<name>
/dev/disk/by-id/scsi-S<vendor>_<model>_<serial>

ata (Advanced Technology Attachment)/atapi (ATA Packet Interface)

/dev/sd*, /dev/sr*

/dev/disk/by-id/ata-<model>_<serial>
/dev/disk/by-id/wwn-<wwn>

cciss (Compaq Command Interface for SCSI-3 Support)

/dev/cciss*

/dev/disk/by-id/cciss-<model>_<serial>
/dev/cciss/<ccissid>

virtio (Virtual Input Output)

/dev/vd*

/dev/disk/by-id/virtio-<serial>

pmem (Persistent Memory)

/dev/pmem*

/dev/disk/by-id/pmem-<uuid>

mmc (MultiMedia Card)

/dev/mmcblk*

/dev/disk/by-id/mmc-<name>_<serial>

memstick (Memory Stick)

/dev/msblk*

/dev/disk/by-id/memstick-<name>_<serial>

Virtual devices

loop

/dev/loop*

/dev/disk/by-loop-inode/<id_loop_backing_device>-<id_loop_backing_inode>
/dev/disk/by-loop-ref/<id_loop_backing_filename>

dm (device-mapper)

/dev/dm-*

/dev/mapper/<name>
/dev/disk/by-id/dm-name-<name>
/dev/disk/by-id/dm-uuid-<uuid>
/dev/disk/by-id/wwn-<wwn>

md (multiple device)

/dev/md*

/dev/md/<devname>
/dev/disk/by-id/md-name-<name>
/dev/disk/by-id/md-uuid-<uuid>

Partitions (either on top of a real or a virtual device)

(any)

(any)

/dev/disk/by-partuuid/<uuid>
/dev/disk/by-partlabel/<label>
/dev/…​/<persistent_symlink_name>-part<number>

LVM PVs (Logical Volume Manager Physical Volumes; either on top of a real or a virtual device)

(any)

(any)

/dev/disk/by-id/lvm-pv-uuid-<pvuuid>

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat, Inc.