At first glance, it can seem that the directories of filesystems presented in Figures 5.1 and 5.2 reside in a single place, in a single storage device. The filesystem directory organization gives no
indication of disk devices or disk space boundaries. The directory tree simply continues over directories and subdirectories in a continuous fashion until the very last file in the tree.
Administrators must be aware that their filesystems could be spread over multiple disk devices. As a matter of fact, this is the most common scenario. The actual filesystem layout is determined by the
filesystem configuration, and the configuration data must be well known to the operating system. The filesystem configuration data defines break points in the overall UNIX filesystem directory
structure by establishing relationships between particular parts of the directory tree and the implemented disk space, i.e., the corresponding disk devices.
The advantages of merging all files into a single hierarchically organized overall UNIX filesystem tree structure are numerous. Identifying each file in the tree simply by its position in the tree,
independently of its real physical location, makes the filesystem much easier to use. Anyone who has ever installed and reinstalled software in a different filesystem environment would appreciate
such a concept very much.
A strict relationship between the filesystem directory organization and the filesystem physical layout, although hidden from the user, does exist. Otherwise, the UNIX filesystem could not work at all. In
UNIX, this relationship is established in a simple and flexible way: each filesystem must be mounted before it can be used.
Mounting is the process that makes a disks contents available to the system, merging them into an overall filesystem directory tree. Dismounting is the process that breaks established logical ties
and makes the disks contents unavailable. Both processes play important roles in the UNIX system. Mounting and dismounting are performed on the level of a filesystem that belongs to the particular
disks space, which is defined as an individual storage unit storage entity. This could be a partition, or a whole disk, or lately even several disks together. Each such filesystem has its own hierarchical,
directory−tree based file structure and all individual filesystems attributes. We will refer to such an individual filesystem as a partitions filesystem, or simply as a filesystem. We are using the term
partition, although another term, volume, would be more appropriate. The term partition has been perfectly serviceable in the past, when disks were partitioned into smaller parts, and the
corresponding partitions were used as basic storage units to create filesystems. But today it is quite common to combine several disks into an equivalent storage entity known as a volume. Although it
could sound confusing and somehow inappropriate to say that a partition consists of several disks, to keep everything simple, we will continue to use partition at least until we learn more about
volumes.
Mounting enables the merging of all these partitions filesystems into a single overall UNIX filesystem. A filesystem can be arbitrarily mounted and dismounted — that is, it can be connected to
any point, or disconnected from the overall UNIX filesystem at will. The only exception is the root filesystem, which is always mounted by the system itself in the root directory, and, while the system
is up, cannot be dismounted.
5.3.1 Mounting a Filesystem
Mounting a UNIX filesystem does more than merely make its data available. Mounting eliminates all device boundaries, making the filesystem device−independent a very important feature in software
installation and implementation. Figure 5.3 illustrates the relationship between disk partitions as
114
Figure 5.3: Mounting filesystems. The root filesystem resides in the first partition of the root disk the first disk — Disk 1, which is
accessible via a special device file devdskc1d0s0 the naming of special device files can be different among different UNIX flavors. Mounting a root filesystem establishes a logical connection
between the special device file devdskc1d0s0 and a mounting point for the root filesystem in the overall UNIX hierarchical directory tree. For the root filesystem, the mounting point must be the root
directory , and the mounting itself must be performed during the system startup booting. A mounted root filesystem cannot be dismounted as long as the system lives.
To mount a new filesystem, the corresponding mounting point or, as we prefer to say, mount−point is required. A mount−point must be an accessible directory in the already mounted directory
hierarchy. It explains why the mounting of the root filesystem must be done during the system startup, as well as why the root filesystem must live as long as the UNIX system itself. The
mounting of the root filesystem happens when no hierarchical directory structure exists at all. Obviously it can be performed only by the system itself. In addition, dismounting of the root
filesystem would be fatal for the system because the complete UNIX filesystem would be lost without chances for a recovery. A filesystem cannot be accessed if its mount−point is not
accessible, and the root filesystem is the beginning of everything. However, once the root filesystem is available, a number of new mount−points can be created and designated to mount other
filesystems.
In Figure 5.3, the root filesystem contains several empty directories: usr, var, home, and project designated to merge other filesystems any mount−points can easily be added by creating a new
directory. While the first three listed filesystems are standard ones please make clear that they are not mandatory as separate filesystems — they could be part of the root filesystem, the fourth one is
very site−specific. This example illustrates a special case where two additional disk partitions named project and docs are dedicated to keep specific project−related data, and only the project
115
Table 5.1: Filesystem Locations and Special Device Files
Filesystem Special Device File Disk and Partition Mount−Point
usr
devdskc1d0s3 disk 1 − part. 3
usr var
devdskc1d0s5 disk 1 − part. 5
var home
devdskc1d1s0 disk 2 − part. 1
home project
devdskc1d1s5 disk 2 − part. 5
project docs
devdskc1d2s2 disk 3 − whole disk projectdocs
Note: Filesystems are usually named by their mount−points; this convention is implemented here.
An additional partition of the disk 1 as it can be seen in the Figure 5.3, identified with devdskc1d0s1 is dedicated to the swap partition. While the swap partition is crucial for the
operating system, it is not an integral part of the UNIX filesystem and that is why it is not included in this discussion.
Four filesystems, usr, var, home, and project, are merged into the root filesystem, while the fifth one, docs, is merged into the project filesystem. This means that the project filesystem must be
mounted before the docs filesystem. Additionally, the project filesystem contains the empty directory .docsprojectdocs after the project filesystem is mounted as a mount−point for the
docs filesystem.
Please note that there is no necessary connection even by convention between a mount−point for a specific filesystem and a particular disk partition and its associated special device file. The
collection of files in a disk partition can be mounted in any directory in an already accessible filesystem. Once the partitions filesystem is mounted, its top−level directory will take the name of its
mount−point. At the same time, the top−level directory of a mounted partitions filesystem replaces the mount−point directory. As a side effect, the eventual files that could reside in the mount−point
directory if it was not empty will disappear once the new filesystem is mounted. These data can no longer be seen and accessed, but they are not erased or overwritten. They remain unchanged but
hidden for future use; they will reappear once the filesystem is dismounted. Obviously, it is highly recommended to select empty directories for the mount−points. Otherwise, disk space taken by
such files will be wasted — the files cannot be accessed, nor used, but they still take up disk space.
A filesystem can only be mounted in one place at one time; that is, a special device file may only designate one mount−point in the directory tree. However, one filesystem can have another
filesystem as a subtree within it.
The previous discussion was related to the local filesystems — the filesystems that reside in local disks. This is not necessarily always the case; UNIX also supports remote disks. Nevertheless, at
this time we will only focus on the local filesystems, and the discussion in this chapter will primarily address these issues.
116
The mount command must be used to mount a filesystem. This is a regular UNIX command that can be invoked from the command line or a script at any time. However, the command is so crucial
for the system that the security precautions require strict superuser privileges for its execution. Even the SUID bit discussed in Section 2.2.2.2.4 doesnt work in the case of the mount command; if
SUID is set, the system will simply reject execution of the command. Any security risk must be avoided, and SUID always carries a bit of it.
The generic format for the mount command is:
mount [key−options] block−special−file mount−point
The mount command attaches a named filesystem, identified by block−special−file, to the overall filesystem hierarchy at an existing directory, identified by mount−point. A number of options are
available.
mount maintains a table of mounted filesystems in the filesystem status file, usually named etcmnttab, or etcmtab. If invoked without an argument, mount displays the contents of this table.
If invoked with a single argument, either block−special−file or mount−point only, mount searches the filesystem configuration file usually named etcvfstab, or etcfstab for a matching entry, and
mounts the specified filesystem in the specified directory.
The key−options can be generic ones, valid for all filesystem types, or specific for the different filesystem types. The following are the most common options:
−p
Print the list of mounted filesystems in a format suitable for use in the filesystem configuration file.
−a
Stands for all. Attempt to mount all the filesystems described in the filesystem configuration file. If a type argument is specified with the −t
option, mount all file systems of that type. Some UNIX platforms have a special mount command for this purpose.
−f
Fake a filesystem status entry in the filesystem status file etc mtab, or etcmnttab, but do not actually mount any filesystem.
−n
Mount a filesystem without making an entry in the filesystem status file.
−v
Verbose. Display messages indicating each filesystem being mounted.
−t type
Specify a file system type see the later text about filesystem types.
−r
Mount the specified file system read−only, even if the configuration entry specifies that it is to be mounted read−write. Physically write−protected and
read−only filesystems should be mounted read−only. Otherwise errors occur when the system attempts to update access times, even if no write
operation is attempted.
−o FS−specific−options
Specify the filesystem−specific options — a comma−separated list of options valid for the corresponding filesystem type see the text about
filesystem types.
The following list shows the common options for most local UNIX filesystems.
Options Meaning
defaults Use all default options.
rw ro Readwrite, or read−only; the default is rw.
117
grpid Create files with BSD semantics for the propagation of the group ID. Under this
option, files inherit the GID of the directory in which they are created, regardless of the directorys SGID bit.
noauto Do not mount the filesystem automatically, only explicitly ignore option −a.
remount A filesystem mounted read−only can be remounted read−write used in
conjunction with rw. intr nointr
Allow, or do not allow, keyboard interrupts to terminate a process that is waiting for an operation on a locked filesystem; the default is intr.
quota noquota Filesystem usage limits are enforced, or are not enforced; the default is noquota. rq
Read−write with quota turned on equivalent to rw,quota. largefiles
nolargefiles Attempt to enable or disable the creation of files greater than 2GB in size; the
filesystem must be created especially to support large files. The default is nolargfiles.
Note: It is highly recommended that you check the manual pages for the mount command before attempting to implement it.
A few examples of how to use the mount command follow; the presented situations are hypothetical.
To mount the local filesystem devxy0g in the directory usr:
mount devxy0g usr
• To mount the hfs filesystem devdskc1d2s0 in the directory home:
mount −t hfs devdskc1d2s0 home
• To fake an entry for nd root:
mount −ft 4.2 devnd0
• To list the filesystems that are currently mounted:
mount
• To mount all ufs file systems:
mount −at ufs
• To save the current mount state:
mount −p etcvfstab
•
5.3.2 Dismounting a Filesystem
