Depending on your past system administration experience, managing storage under Red Hat Linux will either be mostly familiar or completely foreign. This section discusses aspects of storage administration specific to Red Hat Linux.
As with all Linux-like operating systems, Red Hat 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 Linux.
Under Red Hat 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:
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 hda or sda.
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.
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
There are instances where it is necessary to access the entire device and not 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 Linux can be found in Section 22.214.171.124 Adding Storage).
Red Hat Linux includes support for many popular file systems, making it possible to easily access the file systems of other operating systems.
This is particularly useful in dual-boot scenarios and when migrating files from one operating system to another.
The supported file systems include (but are not limited to):
The following sections explore the more popular file systems in greater detail.
Until recently, the ext2 file system had been the standard file system for Red Hat 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 Linux.
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.
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 Linux system administrators will likely see ISO 9660-formatted data in two places:
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 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 Linux is able to correctly interpret ISO 9660 file systems using both the Rock Ridge and Joliet extensions.
Red Hat 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 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.
In order to access any file system, it is first necessary to mount it. By mounting a file system, you direct Red Hat Linux to make a specific partition (on a specific device) available to the system. Likewise, when access to a particular file system is no longer desired, it is necessary to umount it.
In order to mount any file system, two pieces of information must be specified:
A device file name representing the desired disk drive and partition
A directory under which the mounted file system will be made available (otherwise known as a mount point)
We have already covered the device files earlier (in Section 5.9.1 Device Naming Conventions), so the following section discusses mount points in more detail.
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 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 hierarchy system-wide and this single directory 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 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:
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 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 will be written to a dedicated partition and will not fill up the operating system's file system.
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 will appear in place of the directory's contents). However, the files will not be harmed and can be accessed after the partition is unmounted.
In addition to mounting and unmounting disk space, it is possible to see what is mounted. There are several different ways of doing this:
Issuing the df command
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
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)
The /proc/mounts file is part of the proc virtual file system. As with the other files under /proc/, the mounts "file" does not exist on any disk drive in your Red Hat Linux system.
In fact, it is not even a file; instead it is a representation of system status made available (by the Linux kernel) in file form.
Using the command cat /proc/mounts, we can view the status of all mounted file systems:
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
As we can see from the above example, the format of /proc/mounts is very similar to that of /etc/mtab. There are a number of file systems mounted that have nothing to do with disk drives. Among these are the /proc/ file system itself (along with two other file systems mounted under /proc/), pseudo-ttys, and shared memory.
While the format is admittedly not very user-friendly, looking at /proc/mounts is the best way to be 100% sure of seeing what is mounted on your Red Hat Linux system, as the kernel is providing this information. Other methods can, under rare circumstances, be inaccurate.
However, most of the time you will likely use a command with more easily-read (and useful) output. The next section describes that command.
While using /etc/mtab or /proc/mounts lets you know what file systems are currently mounted, it does little beyond that. Most of the time you are more interested in one particular aspect of the file systems that are currently mounted — the amount of free space on them.
For this, we can use the df command. Here is some sample output from df:
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
Several differences with /etc/mtab and /proc/mount are immediately obvious:
An easy-to-read heading is displayed
With the exception of the shared memory file system, only disk-based file systems are shown
Total size, used space, free space, and percentage in use figures are displayed
That last point is probably the most important because every system administrator will eventually have to deal with a system that has run out of free disk space. With df it is very easy to see where the problem lies.
There are two major technologies used for implemented network-accessible storage under Red Hat Linux:
The following sections describe these technologies.
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 Linux Customization Guide.
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 Linux supports SMB via the Samba server program. The Red Hat Linux Customization Guide includes information on configuring Samba.
When a Red Hat Linux system is newly-installed, all the disk partitions defined and/or created during the installation are configured to be automatically mounted whenever the system boots. However, what happens when additional disk drives are added to a system after the installation is done? The answer is "nothing" because the system was not configured to mount them automatically. However, this is easily changed.
The answer lies in the /etc/fstab file. This file is used to control what file systems are mounted when the system boots, as well as to supply default values for other file systems that may be mounted manually from time to time. Here is a sample /etc/fstab file:
LABEL=/ / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 LABEL=/home /home ext3 defaults 1 2 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 /dev/sda2 swap swap defaults 0 0 /dev/cdrom /mnt/cdrom iso9660 noauto,owner,kudzu,ro 0 0 /dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0
Each line represents one file system and contains the following fields:
File system specifier — For disk-based file systems, either a device file or a device label specification
Mount point — Except for swap partitions, this field specifies the mount point to be used when the file system is mounted
File system type — The type of file system present on the specified device (note that auto may be specified to select automatic detection of the file system to be mounted, which is handy for removable media units such as diskette drives)
Mount options — A comma-separated list of options that can be used to control mount's behavior
Dump frequency — If the dump backup utility is used, the number in this field will control dump's handling of the specified file system
File system check order — Controls the order in which the file system checker fsck checks the integrity of the file systems
There are different ways of monitoring disk space under Red Hat Linux. You can manually monitor disk space using the df command. Or you can automatically monitor disk space using the diskcheck utility program.
The following sections explore these methods in more detail.
The easiest way to see how much free disk space is available on a system is to use the df command. Here is an example of df in action:
Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda3 8428196 4282228 3717836 54% / /dev/sda1 124427 18815 99188 16% /boot /dev/sda4 8428196 3801644 4198420 48% /home none 644600 0 644600 0% /dev/shm
As we can see, df lists every mounted file system and provides information such as device size (under the 1k-blocks column), as well as the space used and still available. However, the easiest thing to do is to scan the Use% column for any numbers nearing 100%.
Using df as a disk space monitoring tool has several benefits:
It is quick and can be done whenever desired
The results are easy to interpret
However, there is one major disadvantage:
It is run manually and is therefore easily forgotten
The next section explores one way of automatically monitoring disk space on a Red Hat Linux system.
The diskcheck program is part of Red Hat Linux and makes a system administrator's life much easier by periodically checking available disk space on all mounted file systems. Diskcheck runs once an hour (using cron) and emails a report of problem file systems.
A configuration file (/etc/diskcheck.conf) provides a means of customizing diskcheck's behavior. Here is a look at the file as it exists after a standard Red Hat Linux installation:
# Default configuration file for diskcheck # Copyright (c) 2001 Red Hat, Inc. all rights reserved. # Disks fuller than 90% will be reported defaultCutoff = 90 # Specify per-disk cut-off amounts to override the default value # listed above. You may specify either mount points or partitions. #cutoff['/dev/hda3'] = 50 #cutoff['/home'] = 50 # List one or more partitions to exclude from the check (space seperated). exclude = "/dev/fd*" # List one or more filesystem types to ignore. # List filesystems in the format -x <filesystem-type> # tmpfs, iso9660 (CD-ROM), and 'none' filesystems are automatically ignored. ignore = "-x nfs" # Who to send the report to. mailTo = "root@localhost" # Who to identify the mail as coming from. mailFrom = "Disk Usage Monitor - diskcheck" # Location of sendmail-like mailer program. mailProg = "/usr/sbin/sendmail"
The format of the diskcheck.conf file is straightforward and can be easily be changed to suit your organization's needs.
While the comments in the configuration file are largely self-explanatory, there is one part of the file that you should change immediately — the mailTo line. Because no system administrator should ever use the root account for any task not requiring root-level access, it is far more preferable to have diskcheck notification email delivered to your personal account.
Here is a sample notification email:
From: Disk.Usage.Monitor.-.firstname.lastname@example.org Subject: Low disk space warning To: email@example.com Date: Fri, 31 Jan 2003 13:40:15 -0500 Disk usage for pigdog.example.com: /dev/hda4 (/) is 91% full -- 5.3G of 5.8G used, 495M remain
By using diskcheck, you can automatically perform a tedious task and rest assured that, if there is a problem, you will know about it via email.
If you depend on diskcheck to alert you to disk space shortages, you should give some thought to the possible impact of running out of disk space on the system to which your email is delivered. If, for example, the file system holding your home directory is on a storage server, and used by others, if it were to rapidly fill up, there might not be sufficient time for a notification email to be delivered before the file system is completely full. The result? No notification email, leaving you with the impression that everything is fine.
For more information on configuring diskcheck, see the chapter on gathering system information in the Red Hat Linux Customization Guide.
While most of the steps required to add or remove storage depend more on the system hardware than the system software, there are aspects of the procedure that are specific to your operating environment. This section explores the steps necessary add and remove storage that are specific to Red Hat Linux.
The process of adding storage to a Red Hat Linux system is relatively straightforward. Here are the steps that are specific to Red Hat Linux:
Formatting the partition(s)
The following sections explore each step in more detail.
Once the disk drive has been installed, it is time to create one or more partitions to make the space available to Red Hat Linux.
There are several different ways 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. The commands necessary to perform these steps using fdisk are included:
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:
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
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.
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.
Save your changes and exit the partitioning program. This is done in fdisk by using the w command:
Command (m for help): w
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, which will result in lost data.
Also make sure you have decided on the best partition size. Always give this matter serious thought, because changing it once the disk drive is in service will be much more difficult.
Formatting partitions under Red Hat Linux is done using the mkfs utility program. However, mkfs does not actually do the work of writing the file-system-specific information onto a disk drive; instead it passes control to one of several other programs that actually create the file system.
This is the time to look at the mkfs.<fstype> man page for the file system you have selected. For example, look at the mkfs.ext3 man page to see the options available to you when creating a new ext3 file system. In general, the mkfs.<fstype> programs provide reasonable defaults for most configurations; however here are some of the options that system administrators most commonly change:
Setting a volume label for later use in /etc/fstab
On very large hard disks, setting a lower percentage of space reserved for the super-user
Setting a non-standard block size and/or bytes per inode for configurations that must support either very large or very small files
Checking for bad blocks before formatting
Once file systems have been created on all the appropriate partitions, the disk drive is properly configured for use.
Next, it is always best to double-check your work by manually mounting the partition(s) and making sure everything is in order. Once everything checks out, it is time to configure your Red Hat Linux system to automatically mount the new file system(s) whenever it boots.
As outlined in Section 5.9.5 Mounting File Systems Automatically with /etc/fstab, you must add the necessary line(s) to /etc/fstab in order to ensure that the new file system(s) are mounted whenever the system reboots. Once you have updated /etc/fstab, test your work by issuing an "incomplete" mount, specifying only the device or mount point. Something similar to one of the following commands will be sufficient:
mount /home mount /dev/hda3
(Replacing /home or /dev/hda3 with the mount point or device for your specific situation.)
If the appropriate /etc/fstab entry is correct, mount will obtain the missing information from it and complete the mount operation.
At this point you can be relatively confident that the new file system will be there the next time the system boots (although if you can afford a quick reboot, it would not hurt to do so — just to be sure).
The process of removing storage from a Red Hat Linux system is relatively straightforward. Here are the steps that are specific to Red Hat Linux:
Remove the disk drive's partitions from /etc/fstab
Unmounting the disk drive's active partitions
Erase the contents of the disk drive
The following sections cover these topics in more detail.
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
Be sure to look for any lines in /etc/fstab for swap partitions as well — they can be easily overlooked.
Next, all access to the disk drive must be terminated. For partitions with active file systems on them, this is done using the unmount command. If a swap partition exists on the disk drive, it must be either be deactivated with the swapoff command, or the system should be rebooted.
Unmounting partitions with the umount command requires you to specify either the device file name, or the partition's mount point:
umount /dev/hda2 umount /home
A partition can only be unmounted if it is not currently in use. If the partition cannot be unmounted while at the normal runlevel, boot into rescue mode and remove the partition's /etc/fstab entry.
When using swapoff to disable swapping to a partition, you must specify the device file name representing the swap partition:
If swapping to a swap partition cannot be disabled using swapoff, boot into rescue mode and remove the partition's /etc/fstab entry.
Erasing the contents of a disk drive under Red Hat 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.
You will see the following output 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.
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 then 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.
Red Hat Linux is capable of keeping track of disk space usage on a per-user and per-group basis through the use of disk quotas. The following section provides an overview of the features present in disk quotas under Red Hat Linux.
Disk quotas under Red Hat Linux have the following features:
Per-user space accounting
Per-group space accounting
Tracks disk block usage
Tracks disk inode usage
The following sections describe each feature in more detail.
Disk quotas under Red Hat Linux can be used on a per-file-system basis. In other words, disk quotas can be enabled or disabled for each file system individually.
This provides a great deal of flexibility to the system administrator. For example, if the /home/ directory was on its own file system, disk quotas could be enabled there, enforcing equitable disk usage by all users. However the root file system could be left without disk quotas, eliminating the complexity of maintaining disk quotas on a file system where only the operating system itself resides.
Disk quotas can perform space accounting on a per-user basis. This means that each user's space usage is tracked individually. It also means that any limitations on usage (which are discussed in later sections) are also done on a per-user basis.
Having the flexibility of tracking and enforcing disk usage for each user individually makes it possible for a system administrator to assign different limits to individual users, according to their responsibilities and storage needs.
Disk quotas can also perform disk usage tracking on a per-group basis. This is ideal for those organizations that use groups as a means of combining different users into a single project-wide resource.
By setting up group-wide disk quotas, the system administrator can more closely manage storage utilization by giving individual users only the disk quota they require for their personal use, while setting larger disk quotas that would be more appropriate for multi-user projects. This can be a great advantage to those organizations that use a "chargeback" mechanism to assign data center costs to those departments and teams that use data center resources.
Disk quotas track disk block usage. Because all the data stored on a file system is stored in blocks, disk quotas are able to directly correlate the files created and deleted on a file system with the amount of storage those files take up.
In addition to tracking disk block usage, disk quotas also can track inode usage. Under Red Hat Linux, inodes are used to store various parts of the file system, but most importantly, inodes hold information for each file. Therefore, by tracking (and controlling) inode usage, it is possible to control the creation of new files.
A hard limit is the absolute maximum number of disk blocks (or inodes) that can be temporarily used by a user (or group). Any attempt to use a single block or inode above the hard limit will fail.
A soft limit is the maximum number of disk blocks (or inodes) that can be permanently used by a user (or group).
The soft limit is set below the hard limit. This allows users to temporarily exceed their soft limit, permitting them to finish whatever they were doing, and giving them some time in which to go through their files and trim back their usage to below their soft limit.
As stated earlier, any disk usage above the soft limit is temporary. It is the grace period that determines the length of time that a user (or group) can extend their usage beyond their soft limit and toward their hard limit.
If a user continues to use more than the soft limit and the grace period expires, no additional disk usage will be permitted until the user (or group) has reduced their usage to a point below the soft limit.
The grace period can be expressed in seconds, minutes, hours, days, weeks, or months, giving the system administrator a great deal of freedom in determining how much time to give users to get their disk usages below their soft limits.
The following sections provide a brief overview of the steps necessary to enable disk quotas under Red Hat Linux. For a more in-depth treatment of this subject, see the chapter on disk quotas in the Red Hat Linux Customization Guide.
In order to use disk quotas, you must first enable them. This process involves several steps:
Remounting the file system(s)
The /etc/fstab file controls the mounting of file systems under Red Hat 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 in order 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 in order 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) have 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.
The edquota program can also be used to set the per-file-system grace period by using the -t option.
There is little actual management required to support disk quotas under Red Hat 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 Linux Customization 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:
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.
In addition to supporting some hardware RAID solutions, Red Hat Linux supports software RAID. There are two ways that software RAID arrays can be created:
While installing Red Hat Linux
After Red Hat Linux has been installed
The following sections review these two methods.
During the normal Red Hat 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, whether you want the partition to be a primary partition, and whether you want to check for bad blocks.
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 will be 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 will be based.
Once the desired arrays have been created, the installation process continues as usual.
For more information on creating software RAID arrays during the Red Hat Linux installation process, refer to the Red Hat Linux Customization Guide.
Creating a RAID array after Red Hat 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 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 special device file name for the RAID array
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 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:
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.
There is little that needs to be done to keep a RAID array operating. As long as no hardware problems crop up, the array should function just as if it were a single physical disk drive. However, just as a system administrator should periodically check the status of all disk drives on the system, the RAID arrays' status should be checked as well.
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 hdc3 522048 blocks [2/2] [UU] md0 : active raid1 hda2 hdc2 4192896 blocks [2/2] [UU] md2 : active raid1 hda1 hdc1 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)
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:
Determine which disk drive contains the failed partition
Correct the problem that caused the failure (most likely by replacing the drive)
Partition the new drive so that the partitions on it are identical to those on the other drive(s) in the array
Issue the following command:
raidhotadd <raid-device> <disk-partition>
Monitor /proc/mdstat to watch the rebuild take place
Here is a command that can be used to watch the rebuild as it takes place:
This command displays the contents of /proc/mdstat, updating it every second.
More information on /etc/fstab can be found in Section 5.9.5 Mounting File Systems Automatically with /etc/fstab.
Note that since the RAID array is composed of partitioned disk space, the device file name of a RAID array does not reflect any partition-level information.