System V Filesystem Directory Organization

usrgames • UNIX game collections — Often removed by administrators. usrpreserve • Preserve directory — Old−fashioned directory to store files. usrspool • Spooling directory — Contains subdirectories for UNIX subsystems that provide different kinds of spooling services, such as: .at for time−scheduled jobs .cron for batch jobs .batch for batch jobs .mail, and .mqueue for the email subsystem .news for news .lpd for the printing subsystem .uucp, and . uucppublic for the UUCP subsystem Some UNIX flavors, for example, SunOS or AIX, introduced more usr subdirectories which are not presented in Figure 5.1, like: usr5bin Executables for System V — In SunOS, stores executables for System V−specific commands; over time the name was changed to usrsbin. usrlpp Licensed program products — In AIX, optional products are stored in this directory; in particular, the subdirectory usrlppbos holds information about the current OS release.

5.2.2 System V Filesystem Directory Organization

The UNIX filesystem directory organization described next was introduced with the SVR4 System V Release 4. We will refer to it as the System V filesystem. The basic directory organization is presented in Figure 5.2. Today, this is the prevailing directory organization, sometimes slightly modified by UNIX vendors. 112 Figure 5.2: System V filesystem directory organization. When comparing the directory structures presented in Figures 5.1 and 5.2, certain organizational changes can be seen. System V reorganized the traditional UNIX filesystem in several ways: The dev directory has been changed. Instead of a flat directory, a number of new subdirectories dedicated to specific devices were added: .dsk for disks, .term for terminals, .mt for magnetic tapes, .pts for pseudo−terminals, as well as .SA for the device−related system administration utilities. • The new directories sbin and usrsbin were introduced; the new names reflected System V binaries. Executable files were moved out of the etc and usretc directories. The contents of bin were moved to usrbin, and the bin and usretc ceased to exist. However, many UNIX flavors set up symbolic links toward the old locations, so the commands may seem to be in both places. • Virtually all system configuration files were placed in the etc directory, organized in the slightly different way. New subdirectories were created to store files in a more appropriate way .default for template configuration files, .bkup for backup configuration files, .skel for site−customized configuration files. In particular, the system rc startup files have been organized in a more flexible way: a separate depot subdirectory for start and stop scripts named .init.d and subdirectories for each system run−level, .rcn.dwere introduced. • Certain types of static data files like manual pages, fonts, spelling data, etc. were stored in the subdirectories under usrshare. It was supposed to share these files among a group of networked systems, eliminating the need for separate copies on each system the name share reflected that idea. • A new top−level directory var was introduced to hold the volatile spooling directories, formerly placed in usrspool. The idea was this: if var represents a separate filesystem that keeps dynamic data, then the root filesystem can remain relatively static after initial system setup. This is an important step toward full support for read−only RO system disks. However, this very good idea is still far from its practical implementation. SunOS also used the var directory. • The lib directory was moved into usrlib. • 113 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