Show Table of Contents
5.9. Red Hat Enterprise Linux-Specific Information
Depending on your past system administration experience, managing storage under Red Hat Enterprise Linux is either mostly familiar or completely foreign. This section discusses aspects of storage administration specific to Red Hat Enterprise Linux.
5.9.1. Device Naming Conventions
As with all Linux-like operating systems, Red Hat Enterprise Linux uses device files to access all hardware (including disk drives). However, the naming conventions for attached storage devices varies somewhat between various Linux and Linux-like implementations. Here is how these device files are named under Red Hat Enterprise Linux.
Device names under Red Hat Enterprise Linux are determined at boot-time.
Therefore, changes made to a system's hardware configuration can result in device names changing when the system reboots. Because of this, problems can result if any device name references in system configuration files are not updated appropriately.
188.8.131.52. Device Files
Under Red Hat Enterprise Linux, the device files for disk drives appear in the
/dev/directory. The format for each file name depends on several aspects of the actual hardware and how it has been configured. The important points are as follows:
- Device type
184.108.40.206.1. Device Type
The first two letters of the device file name refer to the specific type of device. For disk drives, there are two device types that are most common:
sd-- The device is SCSI-based
hd-- The device is ATA-based
More information about ATA and SCSI can be found in Section 5.3.2, “Present-Day Industry-Standard Interfaces”.
Following the two-letter device type are one or two letters denoting the specific unit. The unit designator starts with "a" for the first unit, "b" for the second, and so on. Therefore, the first hard drive on your system may appear as
SCSI's ability to address large numbers of devices necessitated the addition of a second unit character to support systems with more than 26 SCSI devices attached. Therefore, the first 26 SCSI hard drives on a system would be named
sdz, the next 26 would be named
sdaz, and so on.
The final part of the device file name is a number representing a specific partition on the device, starting with "1." The number may be one or two digits in length, depending on the number of partitions written to the specific device. Once the format for device file names is known, it is easy to understand what each refers to. Here are some examples:
/dev/hda1-- The first partition on the first ATA drive
/dev/sdb12-- The twelfth partition on the second SCSI drive
/dev/sdad4-- The fourth partition on the thirtieth SCSI drive
220.127.116.11.4. Whole-Device Access
There are instances where it is necessary to access the entire device and not just a specific partition. This is normally done when the device is not partitioned or does not support standard partitions (such as a CD-ROM drive). In these cases, the partition number is omitted:
/dev/hdc-- The entire third ATA device
/dev/sdb-- The entire second SCSI device
However, most disk drives use partitions (more information on partitioning under Red Hat Enterprise Linux can be found in Section 18.104.22.168, “Adding Storage”).
22.214.171.124. Alternatives to Device File Names
Because adding or removing mass storage devices can result in changes to the device file names for existing devices, there is a risk of storage not being available when the system reboots. Here is an example of the sequence of events leading to this problem:
- The system administrator adds a new SCSI controller so that two new SCSI drives can be added to the system (the existing SCSI bus is completely full)
- The original SCSI drives (including the first drive on the bus:
/dev/sda) are not changed in any way
- The system is rebooted
- The SCSI drive formerly known as
/dev/sdanow has a new name, because the first SCSI drive on the new controller is now
In theory, this sounds like a terrible problem. However, in practice it rarely is. It is rarely a problem for a number of reasons. First, hardware reconfigurations of this type happen rarely. Second, it is likely that the system administrator has scheduled downtime to make the necessary changes; downtimes require careful planning to ensure the work being done does not take longer than the alloted time. This planning has the side benefit of bringing to light any issues related to device name changes.
However, some organizations and system configurations are more likely to run into this issue. Organizations that require frequent reconfigurations of storage to meet their needs often use hardware capable of reconfiguration without requiring downtime. Such hotpluggable hardware makes it easy to add or remove storage. But under these circumstances device naming issues can become a problem. Fortunately, Red Hat Enterprise Linux contains features that make device name changes less of a problem.
126.96.36.199.1. File System Labels
Some file systems (which are discussed further in Section 5.9.2, “File System Basics”) have the ability to store a label -- a character string that can be used to uniquely identify the data the file system contains. Labels can then be used when mounting the file system, eliminating the need to use the device name.
File system labels work well; however, file system labels must be unique system-wide. If there is ever more than one file system with the same label, you may not be able to access the file system you intended to. Also note that system configurations which do not use file systems (some databases, for example) cannot take advantage of file system labels.
devlabelsoftware attempts to address the device naming issue in a different manner than file system labels. The
devlabelsoftware is run by Red Hat Enterprise Linux whenever the system reboots (and whenever hotpluggable devices are inserted or removed).
devlabelruns, it reads its configuration file (
/etc/sysconfig/devlabel) to obtain the list of devices for which it is responsible. For each device on the list, there is a symbolic link (chosen by the system administrator) and the device's UUID (Universal Unique IDentifier).
devlabelcommand makes sure the symbolic link always refers to the originally-specified device -- even if that device's name has changed. In this way, a system administrator can configure a system to refer to
/dev/sda12, for example.
Because the UUID is obtained directly from the device,
devlabelmust only search the system for the matching UUID and update the symbolic link appropriately.
For more information on
devlabel, refer to the System Administrators Guide.