Este contenido no está disponible en el idioma seleccionado.
25.8. Persistent Naming
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 when used in order to avoid inadvertently accessing the wrong device, particularly when installing to or reformatting drives.
25.8.1. Major and Minor Numbers of Storage Devices
Storage devices managed by the
sd driver are identified internally by a collection of major device numbers and their associated minor numbers. The major device numbers used for this purpose are not in a contiguous range. Each storage device is represented by a major number and a range of minor numbers, which are used to identify either the entire device or a partition within the device. There is a direct association between the major and minor numbers allocated to a device and numbers in the form of sd<letter(s)>[number(s)]. Whenever the sd driver detects a new device, an available major number and minor number range is allocated. Whenever a device is removed from the operating system, the major number and minor number range is freed for later reuse.
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 associated sd names can change if the order of device detection changes. Although this is unusual with some hardware configurations (for example, with an internal SCSI controller and disks that have their SCSI target ID assigned by their physical location within a chassis), it can nevertheless occur. Examples of situations where this can happen are as follows:
- A disk may fail to power up or respond to the SCSI controller. This will result in it not being detected by the normal device probe. The disk will not be accessible to the system and subsequent devices will have their major and minor number range, including the associated
sdnames shifted down. For example, if a disk normally referred to assdbis not detected, a disk that is normally referred to assdcwould instead appear assdb. - A SCSI controller (host bus adapter, or HBA) may fail to initialize, causing all disks connected to that HBA to not be detected. Any disks connected to subsequently probed HBAs would be assigned different major and minor number ranges, and different associated
sdnames. - The order of driver initialization could change if different types of HBAs are present in the system. This would cause the disks connected to those HBAs to be detected in a different order. This can also occur if HBAs are moved to different PCI slots on the system.
- Disks connected to the system with Fibre Channel, iSCSI, or FCoE adapters might be inaccessible at the time the storage devices are probed, due to a storage array or intervening switch being powered off, for example. This could occur when a system reboots after a power failure, if the storage array takes longer to come online than the system take to boot. Although some Fibre Channel drivers support a mechanism to specify a persistent SCSI target ID to WWPN mapping, this will not cause the major and minor number ranges, and the associated
sdnames to be reserved, it will only provide consistent SCSI target ID numbers.
These reasons make it undesirable to use the major and minor number range or the associated
sd names when referring to devices, such as in the /etc/fstab file. There is the possibility that the wrong device will be mounted and data corruption could result.
Occasionally, however, it is still necessary to refer to the
sd names even when another mechanism is used (such as when errors are reported by a device). This is because the Linux kernel uses sd names (and also SCSI host/channel/target/LUN tuples) in kernel messages regarding the device.
25.8.2. World Wide Identifier (WWID)
The World Wide Identifier (WWID) can be used in reliably identifying devices. It is a persistent, system-independent ID that the SCSI Standard requires from all SCSI 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.
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). The mappings from these WWIDs to the current /dev/sd names can be seen in the symlinks maintained in the /dev/disk/by-id/ directory.
Example 25.4. WWID
For example, a device with a page
0x83 identifier would have:
scsi-3600508b400105e210000900000490000 -> ../../sda
Or, a device with a page
0x80 identifier would have:
scsi-SSEAGATE_ST373453LW_3HW1RHM6 -> ../../sda
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 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/sd name, and the major:minor number.
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.
Important
If you use
user_friendly_names, then additional steps are required to obtain consistent names in a cluster. Refer to the Consistent Multipath Device Names in a Cluster section in the DM Multipath book.
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.
25.8.3. Device Names Managed by the udev Mechanism in /dev/disk/by-*
The
udev mechanism consists of three major components:
- The kernel
- Generates events that are sent to user space when devices are added, removed, or changed.
- The
udevdservice - Receives the events.
- The
udevrules - Specifies the action to take when the
udevservice receives the kernel events.
This mechanism is used for all types of devices in Linux, not just for storage devices. In the case of storage devices, Red Hat Enterprise Linux contains
udev rules that create symbolic links in the /dev/disk/ directory allowing storage devices to be referred to by their contents, a unique identifier, their serial number, or the hardware path used to access the device.
/dev/disk/by-label/- Entries in this directory provide a symbolic name that refers to the storage device by a label in the contents (that is, the data) stored on the device. The blkid utility is used to read data from the device and determine a name (that is, a label) for the device. For example:
/dev/disk/by-label/Boot
Note
The information is obtained from the contents (that is, the data) on the device so if the contents are copied to another device, the label will remain the same.The label can also be used to refer to the device in/etc/fstabusing the following syntax:LABEL=Boot
/dev/disk/by-uuid/- Entries in this directory provide a symbolic name that refers to the storage device by a unique identifier in the contents (that is, the data) stored on the device. The blkid utility is used to read data from the device and obtain a unique identifier (that is, the UUID) for the device. For example:
UUID=3e6be9de-8139-11d1-9106-a43f08d823a6
/dev/disk/by-id/- Entries in this directory provide a symbolic name that refers to the storage device by a unique identifier (different from all other storage devices). The identifier is a property of the device but is not stored in the contents (that is, the data) on the devices. For example:
/dev/disk/by-id/scsi-3600508e000000000ce506dc50ab0ad05
/dev/disk/by-id/wwn-0x600508e000000000ce506dc50ab0ad05
The id is obtained from the world-wide ID of the device, or the device serial number. The/dev/disk/by-id/entries may also include a partition number. For example:/dev/disk/by-id/scsi-3600508e000000000ce506dc50ab0ad05-part1
/dev/disk/by-id/wwn-0x600508e000000000ce506dc50ab0ad05-part1
/dev/disk/by-path/- Entries in this directory provide a symbolic name that refers to the storage device by the hardware path used to access the device, beginning with a reference to the storage controller in the PCI hierarchy, and including the SCSI host, channel, target, and LUN numbers and, optionally, the partition number. Although these names are preferable to using major and minor numbers or
sdnames, caution must be used to ensure that the target numbers do not change in a Fibre Channel SAN environment (for example, through the use of persistent binding) and that the use of the names is updated if a host adapter is moved to a different PCI slot. In addition, there is the possibility that the SCSI host numbers could change if a HBA fails to probe, if drivers are loaded in a different order, or if a new HBA is installed on the system. An example of by-path listing is:/dev/disk/by-path/pci-0000:03:00.0-scsi-0:1:0:0
The/dev/disk/by-path/entries may also include a partition number, such as:/dev/disk/by-path/pci-0000:03:00.0-scsi-0:1:0:0-part1
25.8.3.1. Limitations of the udev Device Naming Convention
The following are some limitations of the
udev naming convention.
- It is possible that the device may not be accessible at the time the query is performed because the
udevmechanism may rely on the ability to query the storage device when theudevrules are processed for audevevent. This is more likely to occur with Fibre Channel, iSCSI or FCoE storage devices when the device is not located in the server chassis. - The kernel may also send
udevevents at any time, causing the rules to be processed and possibly causing the/dev/disk/by-*/links to be removed if the device is not accessible. - There can be a delay between when the
udevevent is generated and when it is processed, such as when a large number of devices are detected and the user-spaceudevdservice takes some amount of time to process the rules for each one). This could 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 may open the device for a brief period of time, making the device inaccessible for other uses.
25.8.3.2. Modifying Persistent Naming Attributes
Although
udev naming attributes are persistent, in that they do not change on their own across system reboots, some are also configurable. You can set custom values for the following persistent naming attributes:
UUID: file system UUIDLABEL: file system label
Because the
UUID and LABEL attributes are related to the file system, the tool you need to use depends on the file system on that partition.
- To change the
UUIDorLABELattributes of an XFS file system, unmount the file system and then use the xfs_admin utility to change the attribute:#umount /dev/device#xfs_admin [-U new_uuid] [-L new_label] /dev/device#udevadm settle - To change the
UUIDorLABELattributes of an ext4, ext3, or ext2 file system, use the tune2fs utility:#tune2fs [-U new_uuid] [-L new_label] /dev/device#udevadm settle
Replace new_uuid with the UUID you want to set; for example,
1cdfbc07-1c90-4984-b5ec-f61943f5ea50. Replace new_label with a label; for example, backup_data.
Note
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 will be able to utilize the new attribute correctly.
You should also use the command after creating new devices; for example, after using the parted tool to create a partition with a custom
PARTUUID or PARTLABEL attribute, or after creating a new file system.
