5.9. Red Hat Enterprise Linux-Specific Information

5.9.1.1. 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

• Unit

• Partition

5.9.1.1.2. Unit

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 hda or sda.

	Tip
	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 sda through sdz, with the 27th named sdaa, the 28th named sdab, and so on through to sddx.

5.9.1.2. 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:

1. 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)

2. The original SCSI drives (including the first drive on the bus: /dev/sda) are not changed in any way

3. The system is rebooted

4. The SCSI drive formerly known as /dev/sda now has a new name, because the first SCSI drive on the new controller is now /dev/sda

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.

5.9.2.1. EXT2

Until recently, the ext2 file system had been the standard file system for Linux. As such, it has received extensive testing and is considered one of the more robust file systems in use today.

However, there is no perfect file system, and ext2 is no exception. One problem that is commonly reported is that an ext2 file system must undergo a lengthy file system integrity check if the system was not cleanly shut down. While this requirement is not unique to ext2, the popularity of ext2, combined with the advent of larger disk drives, meant that file system integrity checks were taking longer and longer. Something had to be done.

The next section describes the approach taken to resolve this issue under Red Hat Enterprise Linux.

5.9.2.2. EXT3

The ext3 file system builds upon ext2 by adding journaling capabilities to the already-proven ext2 codebase. As a journaling file system, ext3 always keeps the file system in a consistent state, eliminating the need for lengthy file system integrity checks.

This is accomplished by writing all file system changes to an on-disk journal, which is then flushed on a regular basis. After an unexpected system event (such as a power outage or system crash), the only operation that needs to take place prior to making the file system available is to process the contents of the journal; in most cases this takes approximately one second.

Because ext3's on-disk data format is based on ext2, it is possible to access an ext3 file system on any system capable of reading and writing an ext2 file system (without the benefit of journaling, however). This can be a sizable benefit in organizations where some systems are using ext3 and some are still using ext2.

5.9.2.3. ISO 9660

In 1987, the International Organization for Standardization (known as ISO) released standard 9660. ISO 9660 defines how files are represented on CD-ROMs. Red Hat Enterprise Linux system administrators will likely see ISO 9660-formatted data in two places:

• CD-ROMs

• Files (usually referred to as ISO images) containing complete ISO 9660 file systems, meant to be written to CD-R or CD-RW media

The basic ISO 9660 standard is rather limited in functionality, especially when compared with more modern file systems. File names may be a maximum of eight characters long and an extension of no more than three characters is permitted. However, various extensions to the standard have become popular over the years, among them:

• Rock Ridge — Uses some fields undefined in ISO 9660 to provide support for features such as long mixed-case file names, symbolic links, and nested directories (in other words, directories that can themselves contain other directories)

• Joliet — An extension of the ISO 9660 standard, developed by Microsoft to allow CD-ROMs to contain long file names, using the Unicode character set

Red Hat Enterprise Linux is able to correctly interpret ISO 9660 file systems using both the Rock Ridge and Joliet extensions.

5.9.2.4. MSDOS

Red Hat Enterprise Linux also supports file systems from other operating systems. As the name for the msdos file system implies, the original operating system supporting this file system was Microsoft's MS-DOS®. As in MS-DOS, a Red Hat Enterprise Linux system accessing an msdos file system is limited to 8.3 file names. Likewise, other file attributes such as permissions and ownership cannot be changed. However, from a file interchange standpoint, the msdos file system is more than sufficient to get the job done.

5.9.2.5. VFAT

The vfat file system was first used by Microsoft's Windows® 95 operating system. An improvement over the msdos file system, file names on a vfat file system may be longer than msdos's 8.3. However, permissions and ownership still cannot be changed.

5.9.3.1. Mount Points

Unless you are used to Linux (or Linux-like) operating systems, the concept of a mount point will at first seem strange. However, it is one of the most powerful and flexible methods of managing file systems developed. With many other operating systems, a full file specification includes the file name, some means of identifying the specific directory in which the file resides, and a means of identifying the physical device on which the file can be found.

With Red Hat Enterprise Linux, a slightly different approach is used. As with other operating systems, a full file specification includes the file's name and the directory in which it resides. However, there is no explicit device specifier.

The reason for this apparent shortcoming is the mount point. On other operating systems, there is one directory hierarchy for each partition. However, on Linux-like systems, there is only one directory hierarchy system-wide and this single hierarchy can span multiple partitions. The key is the mount point. When a file system is mounted, that file system is made available as a set of subdirectories under the specified mount point.

This apparent shortcoming is actually a strength. It means that seamless expansion of a Linux file system is possible, with every directory capable of acting as a mount point for additional disk space.

As an example, assume a Red Hat Enterprise Linux system contained a directory foo in its root directory; the full path to the directory would be /foo/. Next, assume that this system has a partition that is to be mounted, and that the partition's mount point is to be /foo/. If that partition had a file by the name of bar.txt in its top-level directory, after the partition was mounted you could access the file with the following full file specification:

/foo/bar.txt

In other words, once this partition has been mounted, any file that is read or written anywhere under the /foo/ directory will be read from or written to that partition.

A commonly-used mount point on many Red Hat Enterprise Linux systems is /home/ — that is because the login directories for all user accounts are normally located under /home/. If /home/ is used as a mount point, all users' files are written to a dedicated partition and will not fill up the operating system's file system.

Tip

Since a mount point is just an ordinary directory, it is possible to write files into a directory that is later used as a mount point. If this happens, what happens to the files that were in the directory originally? For as long as a partition is mounted on the directory, the files are not accessible (the mounted file system appears in place of the directory's contents). However, the files will not be harmed and can be accessed after the partition is unmounted.

5.9.3.2. Seeing What is Mounted

In addition to mounting and unmounting disk space, it is possible to see what is mounted. There are several different ways of doing this:

• Viewing /etc/mtab

• Viewing /proc/mounts

• Issuing the df command

5.9.3.2.1. Viewing /etc/mtab

The file /etc/mtab is a normal file that is updated by the mount program whenever file systems are mounted or unmounted. Here is a sample /etc/mtab:

/dev/sda3 / ext3 rw 0 0 none /proc proc rw 0 0 usbdevfs /proc/bus/usb usbdevfs rw 0 0 /dev/sda1 /boot ext3 rw 0 0 none /dev/pts devpts rw,gid=5,mode=620 0 0 /dev/sda4 /home ext3 rw 0 0 none /dev/shm tmpfs rw 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0

	Note
	The /etc/mtab file is meant to be used to display the status of currently-mounted file systems only. It should not be manually modified.

Each line represents a file system that is currently mounted and contains the following fields (from left to right):

• The device specification

• The mount point

• The file system type

• Whether the file system is mounted read-only (ro) or read-write (rw), along with any other mount options

• Two unused fields with zeros in them (for compatibility with /etc/fstab[1])

rootfs / rootfs rw 0 0
/dev/root / ext3 rw 0 0
/proc /proc proc rw 0 0
usbdevfs /proc/bus/usb usbdevfs rw 0 0
/dev/sda1 /boot ext3 rw 0 0
none /dev/pts devpts rw 0 0
/dev/sda4 /home ext3 rw 0 0
none /dev/shm tmpfs rw 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0

Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/sda3              8428196   4280980   3719084  54% /
/dev/sda1               124427     18815     99188  16% /boot
/dev/sda4              8428196   4094232   3905832  52% /home
none                    644600         0    644600   0% /dev/shm

5.9.4.1. NFS

As the name implies, the Network File System (more commonly known as NFS) is a file system that may be accessed via a network connection. With other file systems, the storage device must be directly attached to the local system. However, with NFS this is not a requirement, making possible a variety of different configurations, from centralized file system servers to entirely diskless computer systems.

However, unlike the other file systems, NFS does not dictate a specific on-disk format. Instead, it relies on the server operating system's native file system support to control the actual I/O to local disk drive(s). NFS then makes the file system available to any operating system running a compatible NFS client.

While primarily a Linux and UNIX technology, it is worth noting that NFS client implementations exist for other operating systems, making NFS a viable technique to share files with a variety of different platforms.

The file systems an NFS server makes available to clients is controlled by the configuration file /etc/exports. For more information, see the exports(5) man page and the Red Hat Enterprise Linux System Administration Guide.

5.9.4.2. SMB

SMB stands for Server Message Block and is the name for the communications protocol used by various operating systems produced by Microsoft over the years. SMB makes it possible to share storage across a network. Present-day implementations often use TCP/IP as the underlying transports; previously NetBEUI was the transport.

Red Hat Enterprise Linux supports SMB via the Samba server program. The Red Hat Enterprise Linux System Administration Guide includes information on configuring Samba.

5.9.6.1. Adding Storage

The process of adding storage to a Red Hat Enterprise Linux system is relatively straightforward. Here are the steps that are specific to Red Hat Enterprise Linux:

• Partitioning

• Formatting the partition(s)

• Updating /etc/fstab

The following sections explore each step in more detail.

5.9.6.1.1. Partitioning

Once the disk drive has been installed, it is time to create one or more partitions to make the space available to Red Hat Enterprise Linux.

There is more than one way of doing this:

• Using the command-line fdisk utility program

• Using parted, another command-line utility program

Although the tools may be different, the basic steps are the same. In the following example, the commands necessary to perform these steps using fdisk are included:

1. Select the new disk drive (the drive's name can be identified by following the device naming conventions outlined in Section 5.9.1 Device Naming Conventions). Using fdisk, this is done by including the device name when you start fdisk:

   fdisk /dev/hda

2. View the disk drive's partition table, to ensure that the disk drive to be partitioned is, in fact, the correct one. In our example, fdisk displays the partition table by using the p command:

   Command (m for help): p Disk /dev/hda: 255 heads, 63 sectors, 1244 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 17 136521 83 Linux /dev/hda2 18 83 530145 82 Linux swap /dev/hda3 84 475 3148740 83 Linux /dev/hda4 476 1244 6176992+ 83 Linux

3. Delete any unwanted partitions that may already be present on the new disk drive. This is done using the d command in fdisk:

   Command (m for help): d Partition number (1-4): 1

   The process would be repeated for all unneeded partitions present on the disk drive.

4. Create the new partition(s), being sure to specify the desired size and file system type. Using fdisk, this is a two-step process — first, creating the partition (using the n command):

   Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First cylinder (1-767): 1 Last cylinder or +size or +sizeM or +sizeK: +512M

   Second, by setting the file system type (using the t command):

   Command (m for help): t Partition number (1-4): 1 Hex code (type L to list codes): 82

   Partition type 82 represents a Linux swap partition.

5. Save your changes and exit the partitioning program. This is done in fdisk by using the w command:

   Command (m for help): w

Warning

When partitioning a new disk drive, it is vital that you are sure the disk drive you are about to partition is the correct one. Otherwise, you may inadvertently partition a disk drive that is already in use, resulting in lost data. Also make sure you have decided on the best partition size. Always give this matter serious thought, because changing it later is much more difficult than taking a bit of time now to think things through.

mount /home
mount /dev/hda3

5.9.6.2. Removing Storage

The process of removing storage from a Red Hat Enterprise Linux system is relatively straightforward. Here are the steps that are specific to Red Hat Enterprise Linux:

• Remove the disk drive's partitions from /etc/fstab

• Unmount the disk drive's active partitions

• Erase the contents of the disk drive

The following sections cover these topics in more detail.

5.9.6.2.1. Remove the Disk Drive's Partitions From /etc/fstab

Using the text editor of your choice, remove the line(s) corresponding to the disk drive's partition(s) from the /etc/fstab file. You can identify the proper lines by one of the following methods:

• Matching the partition's mount point against the directories in the second column of /etc/fstab

• Matching the device's file name against the file names in the first column of /etc/fstab

	Tip
	Be sure to look for any lines in /etc/fstab that identify swap partitions on the disk drive to be removed; they can be easily overlooked.

umount /dev/hda2
umount /home
            

swapoff /dev/hda4
            

5.9.6.2.3. Erase the Contents of the Disk Drive

Erasing the contents of a disk drive under Red Hat Enterprise Linux is a straightforward procedure.

After unmounting all of the disk drive's partitions, issue the following command (while logged in as root):

badblocks -ws <device-name>

Where <device-name> represents the file name of the disk drive you wish to erase, excluding the partition number. For example, /dev/hdb for the second ATA hard drive.

The following output is displayed while badblocks runs:

Writing pattern 0xaaaaaaaa: done Reading and comparing: done Writing pattern 0x55555555: done Reading and comparing: done Writing pattern 0xffffffff: done Reading and comparing: done Writing pattern 0x00000000: done Reading and comparing: done

Keep in mind that badblocks is actually writing four different data patterns to every block on the disk drive. For large disk drives, this process can take a long time — quite often several hours.

Important

Many companies (and government agencies) have specific methods of erasing data from disk drives and other data storage media. You should always be sure you understand and abide by these requirements; in many cases there are legal ramifications if you fail to do so. The example above should in no way be considered the ultimate method of wiping a disk drive. However, it is much more effective than using the rm command. That is because when you delete a file using rm it only marks the file as deleted — it does not erase the contents of the file.

5.9.7.1. Some Background on Disk Quotas

Disk quotas under Red Hat Enterprise Linux have the following features:

• Per-file-system implementation

• Per-user space accounting

• Per-group space accounting

• Tracks disk block usage

• Tracks disk inode usage

• Hard limits

• Soft limits

• Grace periods

The following sections describe each feature in more detail.

5.9.7.2. Enabling Disk Quotas

	Note
	The following sections provide a brief overview of the steps necessary to enable disk quotas under Red Hat Enterprise Linux. For a more in-depth treatment of this subject, see the chapter on disk quotas in the Red Hat Enterprise Linux System Administration Guide.

To use disk quotas, you must first enable them. This process involves several steps:

1. Modifying /etc/fstab

2. Remounting the file system(s)

3. Running quotacheck

4. Assigning quotas

The /etc/fstab file controls the mounting of file systems under Red Hat Enterprise Linux. Because disk quotas are implemented on a per-file-system basis, there are two options — usrquota and grpquota — that must be added to that file to enable disk quotas.

The usrquota option enables user-based disk quotas, while the grpquota option enables group-based quotas. One or both of these options may be enabled by placing them in the options field for the desired file system.

The affected file system(s) then must be unmounted and remounted for the disk quota-related options to take affect.

Next, the quotacheck command is used to create the disk quota files and to collect the current usage information from already existing files. The disk quota files (named aquota.user and aquota.group for user- and group-based quotas) contain the necessary quota-related information and reside in the file system's root directory.

To assign disk quotas, the edquota command is used.

This utility program uses a text editor to display the quota information for the user or group specified as part of the edquota command. Here is an example:

 Disk quotas for user matt (uid 500):
  Filesystem      blocks       soft       hard     inodes     soft     hard
  /dev/md3       6618000          0          0      17397        0        0

This shows that user matt is currently using over 6GB of disk space, and over 17,000 inodes. No quota (soft or hard) has yet been set for either disk blocks or inodes, meaning that there is no limit to the disk space and inodes that this user can currently use..

Using the text editor displaying the disk quota information, the system administrator can then modify the soft and hard limits as desired:

Disk quotas for user matt (uid 500):
  Filesystem      blocks       soft       hard     inodes     soft     hard
  /dev/md3       6618000    6900000    7000000      17397        0        0

In this example, user matt has been given a soft limit of 6.9GB and a hard limit of 7GB. No soft or hard limit on inodes has been set for this user.

	Tip
	The edquota program can also be used to set the per-file-system grace period by using the -t option.

5.9.7.3. Managing Disk Quotas

There is little actual management required to support disk quotas under Red Hat Enterprise Linux. Essentially, all that is required is:

• Generating disk usage reports at regular intervals (and following up with users that seem to be having trouble effectively managing their allocated disk space)

• Making sure that the disk quotas remain accurate

Creating a disk usage report entails running the repquota utility program. Using the command repquota /home produces this output:

*** Report for user quotas on device /dev/md3
Block grace time: 7days; Inode grace time: 7days
                        Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
root      --   32836       0       0              4     0     0       
matt      -- 6618000 6900000 7000000          17397     0     0       

More information about repquota can be found in the Red Hat Enterprise Linux System Administration Guide, in the chapter on disk quotas.

Whenever a file system is not unmounted cleanly (due to a system crash, for example), it is necessary to run quotacheck. However, many system administrators recommend running quotacheck on a regular basis, even if the system has not crashed.

The process is similar to the initial use of quotacheck when enabling disk quotas.

Here is an example quotacheck command:

quotacheck -avug

The easiest way to run quotacheck on a regular basis do this is to use cron. Most system administrators run quotacheck once a week, though there may be valid reasons to pick a longer or shorter interval, depending on your specific conditions.

5.9.8.1. While Installing Red Hat Enterprise Linux

During the normal Red Hat Enterprise Linux installation process, RAID arrays can be created. This is done during the disk partitioning phase of the installation.

To begin, you must manually partition your disk drives using Disk Druid. You must first create a new partition of the type "software RAID." Next, select the disk drives that you want to be part of the RAID array in the Allowable Drives field. Continue by selecting the desired size and whether you want the partition to be a primary partition.

Once you have created all the partitions required for the RAID array(s) that you want to create, you must then use the RAID button to actually create the arrays. You are then presented with a dialog box where you can select the array's mount point, file system type, RAID device name, RAID level, and the "software RAID" partitions on which this array is to be based.

Once the desired arrays have been created, the installation process continues as usual.

	Tip
	For more information on creating software RAID arrays during the Red Hat Enterprise Linux installation process, refer to the Red Hat Enterprise Linux System Administration Guide.

5.9.8.2. After Red Hat Enterprise Linux Has Been Installed

Creating a RAID array after Red Hat Enterprise Linux has been installed is a bit more complex. As with the addition of any type of disk storage, the necessary hardware must first be installed and properly configured.

Partitioning is a bit different for RAID than it is for single disk drives. Instead of selecting a partition type of "Linux" (type 83) or "Linux swap" (type 82), all partitions that are to be part of a RAID array must be set to "Linux raid auto" (type fd).

Next, it is necessary to create the /etc/raidtab file. This file is responsible for the proper configuration of all RAID arrays on your system. The file format (which is documented in the raidtab(5) man page) is relatively straightforward. Here is an example /etc/raidtab entry for a RAID 1 array:

raiddev             /dev/md0
raid-level                  1
nr-raid-disks               2
chunk-size                  64k
persistent-superblock       1
nr-spare-disks              0
    device          /dev/hda2
    raid-disk     0
    device          /dev/hdc2
    raid-disk     1

Some of the more notable sections in this entry are:

• raiddev — Shows the device file name for the RAID array[2]

• raid-level — Defines the RAID level to be used by this RAID array

• nr-raid-disks — Indicates how many physical disk partitions are to be part of this array

• nr-spare-disks — Software RAID under Red Hat Enterprise Linux allows the definition of one or more spare disk partitions; these partitions can automatically take the place of a malfunctioning disk

• device, raid-disk — Together, they define the physical disk partitions that make up the RAID array

Next, it is necessary to actually create the RAID array. This is done with the mkraid program. Using our example /etc/raidtab file, we would create the /dev/md0 RAID array with the following command:

mkraid /dev/md0

The RAID array /dev/md0 is now ready to be formatted and mounted. The process at this point is no different than for formatting and mounting a single disk drive.

5.9.9.1. Checking Array Status With /proc/mdstat

The file /proc/mdstat is the easiest way to check on the status of all RAID arrays on a particular system. Here is a sample mdstat (view with the command cat /proc/mdstat):

Personalities : [raid1] 
read_ahead 1024 sectors
md1 : active raid1 hda3[0] hdc3[1]
      522048 blocks [2/2] [UU]
      
md0 : active raid1 hda2[0] hdc2[1]
      4192896 blocks [2/2] [UU]
      
md2 : active raid1 hda1[0] hdc1[1]
      128384 blocks [2/2] [UU]
      
unused devices: <none>

On this system, there are three RAID arrays (all RAID 1). Each RAID array has its own section in /proc/mdstat and contains the following information:

• The RAID array device name (not including the /dev/ part)

• The status of the RAID array

• The RAID array's RAID level

• The physical partitions that currently make up the array (followed by the partition's array unit number)

• The size of the array

• The number of configured devices versus the number of operative devices in the array

• The status of each configured device in the array (U meaning the device is OK, and _ indicating that the device has failed)

5.9.9.2. Rebuilding a RAID array with raidhotadd

Should /proc/mdstat show that a problem exists with one of the RAID arrays, the raidhotadd utility program should be used to rebuild the array. Here are the steps that would need to be performed:

1. Determine which disk drive contains the failed partition

2. Correct the problem that caused the failure (most likely by replacing the drive)

3. Partition the new drive so that the partitions on it are identical to those on the other drive(s) in the array

4. Issue the following command:

   raidhotadd <raid-device> <disk-partition>

5. Monitor /proc/mdstat to watch the rebuild take place

	Tip
	Here is a command that can be used to watch the rebuild as it takes place: watch -n1 cat /proc/mdstat This command displays the contents of /proc/mdstat, updating it every second.