Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 6. Overview of persistent naming attributes
As a system administrator, you need to refer to storage volumes by using persistent naming attributes to build storage setups that are reliable over multiple system boots.
6.1. Disadvantages of non-persistent naming attributes Copier lienLien copié sur presse-papiers!
Red Hat Enterprise Linux provides a number of ways to identify storage devices. It is important to use the correct option to identify each device. This helps avoid inadvertently accessing the wrong device.
It is particularly important when installing to or reformatting drives.
Traditionally, non-persistent names in the form of /dev/sd(major number)(minor number) are used on Linux to refer to storage devices. The major and minor number range and associated sd names are allocated for each device when it is detected. This means that the association between the major and minor number range and the associated sd names can change. This can happen if the order of device detection changes.
Such a change in the ordering might occur in the following situations:
- The parallelization of the system boot process detects storage devices in a different order with each system boot.
-
A disk fails to power up or respond to the Small Computer System Interface (SCSI) controller. This results in it not being detected by the normal device probe. The disk is not accessible to the system. As a result, subsequent devices will have their major and minor number ranges shifted down. This also affects the associated
sdnames. For example, a disk normally referred to assdbmight not be detected. In that case, a disk normally referred to assdcwould appear assdbinstead. -
A SCSI controller (host bus adapter, or HBA) fails to initialize, causing all disks connected to that HBA to not be detected. Any disks connected to subsequently probed HBAs are assigned different major and minor number ranges, and different associated
sdnames. - The order of driver initialization changes if different types of HBAs are present in the system. This causes the disks connected to those HBAs to be detected in a different order. This might also occur if HBAs are moved to different PCI slots on the system.
-
Disks connected through Fibre Channel, Internet Small Computer System Interface (iSCSI), or Fibre Channel over Ethernet (FCoE) adapters might be inaccessible when probed. For example, this can happen due to a storage array or intervening switch being powered off. This might occur when a system reboots after a power failure and the storage array takes longer to come online than the system. Some Fibre Channel drivers support a mechanism to specify a persistent SCSI target ID to World Wide Port Name (WWPN) mapping. However, this does not reserve the major and minor number ranges or the associated
sdnames. It only provides consistent SCSI target ID numbers.
These reasons make it undesirable to use the major and minor number range or associated sd names when referring to devices. This is especially true in files such as /etc/fstab. There is the possibility that the wrong device will be mounted and data corruption might result.
Occasionally, it is still necessary to refer to sd names, even when another mechanism is used. This can occur when errors are reported by a device. The Linux kernel uses sd names in kernel messages about the device. It also uses SCSI host, channel, target, and Logical Unit Number (LUN) tuples.
6.2. File system and device identifiers Copier lienLien copié sur presse-papiers!
File system identifiers are tied to the file system itself, while device identifiers are linked to the physical block device. Understanding the difference is important for proper storage management.
File system identifiers
File system identifiers are tied to a particular file system created on a block device. The identifier is also stored as part of the file system. If you copy the file system to a different device, it still carries the same file system identifier.
However, if you rewrite the device, such as by formatting it with the mkfs utility, the device loses the attribute.
File system identifiers include:
- Unique identifier (UUID)
- Label
Device identifiers
Device identifiers are tied to a block device: for example, a disk or a partition. If you rewrite the device, such as by formatting it with the mkfs utility, the device keeps the attribute. This is because it is not stored in the file system.
Device identifiers include:
- World Wide Identifier (WWID)
- Partition UUID
- Serial number
Recommendations
- Some file systems, such as logical volumes, span multiple devices. Access these file systems by using file system identifiers rather than device identifiers.
6.3. Device names managed by the udev mechanism in /dev/disk/ Copier lienLien copié sur presse-papiers!
The udev mechanism is used for all types of devices in Linux, and is not limited only for storage devices. It provides different kinds of persistent naming attributes in the /dev/disk/ directory. In the case of storage devices, Red Hat Enterprise Linux contains udev rules that create symbolic links in the /dev/disk/ directory.
You can refer to storage devices by:
- Their content
- A unique identifier
- Their serial number.
Although udev naming attributes are persistent, in that they do not change on their own across system reboots, some are also configurable.
6.3.1. File system identifiers Copier lienLien copié sur presse-papiers!
The UUID attribute in /dev/disk/by-uuid/
Entries in this directory provide a symbolic name that refers to the storage device by a unique identifier (UUID) in the content (that is, the data) stored on the device. For example:
/dev/disk/by-uuid/3e6be9de-8139-11d1-9106-a43f08d823a6
You can use the UUID to refer to the device in the /etc/fstab file by using the following syntax:
UUID=3e6be9de-8139-11d1-9106-a43f08d823a6
You can configure the UUID attribute when creating a file system, and you can also change it later on.
The Label attribute in /dev/disk/by-label/
Entries in this directory provide a symbolic name that refers to the storage device by a label in the content (that is, the data) stored on the device. For example:
/dev/disk/by-label/Boot
You can use the label to refer to the device in the /etc/fstab file by using the following syntax:
LABEL=Boot
You can configure the Label attribute when creating a file system, and you can also change it later on.
6.3.2. Device identifiers Copier lienLien copié sur presse-papiers!
The WWID attribute in /dev/disk/by-id/
The World Wide Identifier (WWID) is a persistent, system-independent identifier required by the Small Computer System Interface (SCSI) standard for all devices. The WWID identifier is guaranteed to be unique for every storage device, and independent of the path that is used to access the device. The identifier is a property of the device but is not stored in the content (that is, the data) on the devices.
This identifier can be obtained by issuing a SCSI Inquiry to retrieve the Device Identification Vital Product Data (page 0x83) or Unit Serial Number (page 0x80).
Red Hat Enterprise Linux automatically maintains the proper mapping from the WWID-based device name to a current /dev/sd name on that system. Applications can use the /dev/disk/by-id/ name to reference the data on the disk, even if the path to the device changes, and even when accessing the device from different systems.
If your are using an NVMe device, you might run into a disk by-id naming change for some vendors, if the serial number of your device has leading whitespace.
Example of WWID mappings:
| WWID symlink | Non-persistent device | Note |
|---|---|---|
|
|
|
A device with a page |
|
|
|
A device with a page |
|
|
| A disk partition |
In addition to these persistent names provided by the system, you can also use udev rules to implement persistent names of your own, mapped to the WWID of the storage.
The Partition UUID attribute in /dev/disk/by-partuuid
The Partition UUID (PARTUUID) attribute identifies partitions as defined by the GUID Partition Table (GPT) partition table.
Example of Partition UUID mappings:
| PARTUUID symlink | Non-persistent device |
|---|---|
|
|
|
|
|
|
|
|
|
The Path attribute in /dev/disk/by-path/
This attribute provides a symbolic name that refers to the storage device by the hardware path used to access the device.
The Path attribute fails if any part of the hardware path (for example, the PCI ID, target port, or LUN number) changes. The Path attribute is therefore unreliable. However, the Path attribute may be useful in one of the following scenarios:
- You need to identify a disk that you are planning to replace later.
- You plan to install a storage service on a disk in a specific location.
6.4. The World Wide Identifier with DM Multipath Copier lienLien copié sur presse-papiers!
You can configure Device Mapper (DM) Multipath to map between the World Wide Identifier (WWID) and non-persistent device names.
If there are multiple paths from a system to a device, DM Multipath uses the WWID to detect this. DM Multipath then presents a single "pseudo-device" in the /dev/mapper/wwid directory, such as /dev/mapper/3600508b400105df70000e00000ac0000.
The command multipath -l shows the mapping to the non-persistent identifiers:
-
Host:Channel:Target:LUN -
/dev/sdname -
major:minornumber
Example 6.1. WWID mappings in a multipath configuration
An example output of the multipath -l command:
3600508b400105df70000e00000ac0000 dm-2 vendor,product
[size=20G][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=0][active]
\_ 5:0:1:1 sdc 8:32 [active][undef]
\_ 6:0:1:1 sdg 8:96 [active][undef]
\_ round-robin 0 [prio=0][enabled]
\_ 5:0:0:1 sdb 8:16 [active][undef]
\_ 6:0:0:1 sdf 8:80 [active][undef]
DM Multipath automatically maintains the proper mapping of each WWID-based device name to its corresponding /dev/sd name on the system. These names are persistent across path changes, and they are consistent when accessing the device from different systems.
When the user_friendly_names feature of DM Multipath is used, the WWID is mapped to a name of the form /dev/mapper/mpathN. By default, this mapping is maintained in the file /etc/multipath/bindings. These mpathN names are persistent as long as that file is maintained.
If you use user_friendly_names, then additional steps are required to obtain consistent names in a cluster.
6.5. Limitations of the udev device naming convention Copier lienLien copié sur presse-papiers!
The udev device naming convention has some challenges and constraints. These include event timing, device accessibility, latency, naming stability, and potential conflicts with external processes in dynamic storage environments.
The following are some limitations of the udev naming convention:
-
It is possible that the device might not be accessible when the query is performed. This is because the
udevmechanism might rely on querying the storage device when processingudevrules for audevevent. This is more likely with Fibre Channel, Internet Small Computer System Interface (iSCSI), or Fibre Channel over Ethernet (FCoE) storage devices. This occurs when the device is not located in the server chassis. -
The kernel might send
udevevents at any time, causing the rules to be processed. This might remove/dev/disk/by-*/links if the device is not accessible. -
There might be a delay between when the
udevevent is generated and when it is processed. This occurs when many devices are detected and the user-spaceudevdservice takes time to process the rules for each one. This might cause a delay between when the kernel detects the device and when the/dev/disk/by-*/names are available. - External programs such as blkid invoked by the rules might open the device briefly. This makes the device temporarily inaccessible for other uses.
-
The device names managed by the
udevmechanism in/dev/disk/may change between major releases, requiring you to update the links.
6.6. Listing persistent naming attributes Copier lienLien copié sur presse-papiers!
You can find out the persistent naming attributes of non-persistent storage devices.
Procedure
To list the Universally Unique Identifier (UUID) and Label attributes, use the
lsblkutility:$ lsblk --fs storage-deviceFor example, view the UUID label of a file system:
$ lsblk --fs /dev/sda1NAME FSTYPE LABEL UUID MOUNTPOINT sda1 xfs Boot afa5d5e3-9050-48c3-acc1-bb30095f3dc4 /bootTo list the PARTUUID attribute, use the
lsblkutility with the--output +PARTUUIDoption:$ lsblk --output +PARTUUIDFor example, view the PARTUUID attribute of a partition:
$ lsblk --output +PARTUUID /dev/sda1NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT PARTUUID sda1 8:1 0 512M 0 part /boot 4cd1448a-01To list the World Wide Identifier (WWID) attribute, examine the targets of symbolic links in the
/dev/disk/by-id/directory.For example, view the WWID of all storage devices on the system:
$ file /dev/disk/by-id/*/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001 symbolic link to ../../sda /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1 symbolic link to ../../sda1 /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2 symbolic link to ../../sda2 /dev/disk/by-id/dm-name-rhel_rhel8-root symbolic link to ../../dm-0 /dev/disk/by-id/dm-name-rhel_rhel8-swap symbolic link to ../../dm-1 /dev/disk/by-id/dm-uuid-LVM-QIWtEHtXGobe5bewlIUDivKOz5ofkgFhP0RMFsNyySVihqEl2cWWbR7MjXJolD6g symbolic link to ../../dm-1 /dev/disk/by-id/dm-uuid-LVM-QIWtEHtXGobe5bewlIUDivKOz5ofkgFhXqH2M45hD2H9nAf2qfWSrlRLhzfMyOKd symbolic link to ../../dm-0 /dev/disk/by-id/lvm-pv-uuid-atlr2Y-vuMo-ueoH-CpMG-4JuH-AhEF-wu4QQm symbolic link to ../../sda2
6.7. Modifying persistent naming attributes Copier lienLien copié sur presse-papiers!
You can change the UUID or Label persistent naming attribute of a file system.
Changing udev attributes happens in the background and might take a long time. The udevadm settle command waits until the change is fully registered, which ensures that your next command is able to use the new attribute correctly.
In the following commands:
-
Replace new-uuid with the UUID you want to set; for example,
1cdfbc07-1c90-4984-b5ec-f61943f5ea50. You can generate a UUID by using theuuidgencommand. -
Replace new-label with a label; for example,
backup_data.
Prerequisites
- If you are modifying the attributes of an XFS file system, unmount it first.
Procedure
To change the UUID or Label attributes of an XFS file system, use the
xfs_adminutility:# xfs_admin -U new-uuid -L new-label storage-device# udevadm settleTo change the UUID or Label attributes of an ext4, ext3, or ext2 file system, use the
tune2fsutility:# tune2fs -U new-uuid -L new-label storage-device# udevadm settleTo change the UUID or Label attributes of a swap volume, use the
swaplabelutility:# swaplabel --uuid new-uuid --label new-label swap-device# udevadm settle