5.9.3. Mounting File Systems

To access any file system, it is first necessary to mount it. By mounting a file system, you direct Red Hat Enterprise 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.
To mount any file system, two pieces of information must be specified:
  • A means of uniquely identifying the desired disk drive and partition, such as device file name, file system label, or devlabel-managed symbolic link
  • A directory under which the mounted file system is to be made available (otherwise known as a mount point)
The following section discusses mount points in more detail. 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:
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.


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.