Red Hat Linux 8.0: The Official Red Hat Linux System Administration Primer | ||
---|---|---|
Prev | Chapter 5. Managing Storage | Next |
A disk drive by itself provides a place to store data, and nothing more. In fact, by itself, the only way to access data on a hard drive is by either specifying the data's physical location (in terms of cylinder, head, and sector), or by its logical location (the 65,321st block) on the disk.
What is needed is a way to more easily keep track of things stored on hard drives; a way of filing information in an easily-accessible way.
That is the role of the file system.
File systems, as the name implies, treat different sets of information as files. Each file is separate from every other. Over and above the information stored within it, each file includes additional information:
The file's name
The file's access permissions
The time and date of the file's creation, access, and modification.
While file systems in the past have included no more complexity than that already mentioned, present-day file systems include mechanisms to make it easier to group related files together. The most commonly-used mechanism is the directory. Often implemented as a special type of file, directories make it possible to create hierarchical structures of files and directories.
However, while most file systems have these attributes in common, they vary in implementation details, meaning that not all file systems can be accessed by all operating systems. Luckily, 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.
Next, we will examine some of file systems that are frequently used under Red Hat Linux.
Until recently, the ext2 file system has been the standard Linux 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 very 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 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 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.
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 discussed here, 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.
In 1987, the International Organization for Standardization (known as ISO) released international 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:
CD-ROMs
Files 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 (often known as 8.3 file names). 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 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.
The vfat file system was first used by Microsoft's Windows® series of operating systems. 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.
Now that we have seen which file systems are most commonly used under Red Hat Linux, let us see how they are used.
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 device (and partition) 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 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 the Section called Device Naming Conventions), so the following section will discuss 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 methods of managing files ever 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:
/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 the partition.
A commonly-used mount point on many Red Hat Linux systems is /home — that is because all user accounts' login directories normally are located under /home, meaning that all users' files can be written to a dedicated partition, and 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. However, they 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:
Viewing /etc/mtab
Viewing /proc/mounts
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 automount(pid1006) /misc autofs rw,fd=5,pgrp=1006,minproto=2,maxproto=3 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0 |
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/, mounts does not exist on any disk drive in your Red Hat Linux system. Instead, these files are representations of system status made available in file form. Using the command cat /proc/mounts, we can view /proc/mounts:
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. 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. Let us look at that command next.
While using /proc/mounts will let you know what file systems are currently mounted, it does little beyond that. Most of the time you will be 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.
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 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 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 CD-ROMs and 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.