24.7. Persistent Naming
/dev/sd* and their Major and Minor Numbers
sddriver 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)><optional number(s)>. Whenever the
sddriver 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.
sdnames are allocated for each device when it is detected. This means that the association between the major and minor number range and associated
sdnames 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 thier 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 proble. 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, should a disk normally referred to as
sdbis not detected, a disk that is normally referred to as
sdcwould instead appear as
- 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
- 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.
sdnames when referring to devices, such as in the
/etc/fstabfile. There is the possibility that the wrong device will be mounted and data corruption could result.
sdnames even when another mechanism is used (such as when errors are reported by a device). This is because the Linux kernel uses
sdnames (and also SCSI host/channel/target/LUN tuples) in kernel messages regarding the device.
0x83) or Unit Serial Number (page
0x80). The mappings from these WWIDs to the current
/dev/sdnames can be seen in the symlinks maintained in the
Example 24.4. WWID
0x83identifier would have:
scsi-3600508b400105e210000900000490000 -> ../../sda
0x80identifier would have:
scsi-SSEAGATE_ST373453LW_3HW1RHM6 -> ../../sda
/dev/sdname 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.
/dev/mapper/wwid, such as
multipath -lshows the mapping to the non-persistent identifiers:
/dev/sdname, and the
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]
/dev/sdname on the system. These names are persistent across path changes, and they are consistent when accessing the device from different systems.
user_friendly_namesfeature (of device-mapper-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
mpathnnames are persistent as long as that file is maintained.
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 Using DM Multipath Configuration and Administration book.
udevrules to implement persistent names of your own, mapped to the WWID of the storage.
24.7.3. Device Names Managed by the
udev mechanism (
udevmechanism consists of three major components:
- The kernel
- Generates events that are sent to user space when devices are added, removed, or changed.
- Receives the events.
- Specifies the action to take when the
udevdaemon receives the kernel events.
udevrules 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.
- 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
blkidprogram is used to read data from the device and determine a name (that is, a label) for the device. For example:
NoteThe 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:
- 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
blkidprogram is used to read data from the device and obtain a unique identifier (that is, the uuid) for the device. For example:
- 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/wwn-0x600508e000000000ce506dc50ab0ad05The id is obtained from the world-wide ID of the device, or the device serial number. The
/dev/disk/by-identries may also include a partition number. For example:
- 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 hierachy, 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-pathentries may also include a partition number, such as:
220.127.116.11. Limitations of the
udev Device 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 the
udevrules are processed for a
udevevent. 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-space
udevddaemon 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
blkidinvoked by the rules may open the device for a brief period of time, making the device inaccessible for other uses.