UNIX System Administration Handbook - Evi Nemeth [45]
5 The Filesystem
Quick: which of the following would you expect to find in a “filesystem”?
• Processes
• Serial ports
• Interprocess communication channels
• Shared memory segments
If the system is UNIX, the answer is “all of the above.” And yes, you might find some files in there, too.
While the basic purpose of a filesystem is to represent and organize the system’s storage resources, programmers have been eager to avoid reinventing the wheel when it comes to managing other types of objects. Frequently, it has proven to be natural and convenient to map such objects into the filesystem namespace. There are some advantages to this unification (consistent programming interface, easy access from the shell) and some disadvantages (Frankenstein-like filesystem implementations), but like it or not, this has become the UNIX way.
The filesystem can be thought of as comprising four main components:
• A namespace – a way of naming things and arranging them in a hierarchy
• An API1
– a set of system calls for navigating and manipulating nodes
• A security model – a scheme for protecting, hiding, and sharing things
• An implementation – code that ties the logical model to an actual disk
Modern UNIX filesystems define an abstract kernel-level interface that accommodates several different back ends. Some portions of the file tree are handled by the traditional disk-based implementation; others are fielded by separate drivers within the kernel. For example, NFS filesystems are handled by a driver that forwards the requested operations to a server on another computer.
NFS, the Network File System, is described in Chapter 17.
Unfortunately, the architectural boundaries are not clearly drawn, and there are quite a few special cases. For example, device files provide a way for programs to communicate with drivers inside the kernel. They are not really data files, but they’re handled by the basic filesystem driver and their characteristics are stored on disk. Perhaps the details would be somewhat different if the filesystem were reimplemented in light of the last few decades’ experience.
Another complicating factor is that modern versions of UNIX tend to support more than one type of disk-based filesystem. In addition to the tried-and-true 4.3BSD-based filesystem that serves as most systems’ default, there may be alternatives that feature higher reliability or easier fault recovery (such as HP-UX’s VXFS), filesystems that support substantially mutated semantics (such as the Solaris and HP-UX access control list extensions), and filesystems that accommodate other systems’ media (such as DOS disks or ISO-9660 CD-ROMs). Those filesystems may vary in their particulars from the standard UNIX filesystem we describe in this chapter.
1. Application Programming Interface, a generic term for the set of routines that a library, operating system, or software package provides for programmers to call.
5.1 PATHNAMES
The filesystem is presented as a single hierarchy that starts at the directory / and continues downward through an arbitrary number of subdirectories. / is also called the root directory.
The list of directories that must be traversed to locate a particular file, together with its filename, form a “pathname.” Pathnames can be either absolute (/tmp/foo) or relative (book3/filesystem). Relative pathnames are interpreted starting at the current directory. You might be accustomed to thinking of the current directory as a feature of the shell, but every process has a current directory.
The terms file, filename, pathname, and path are more or less interchangeable (or at least, we use them interchangeably in this book). Filename and path can be used for both absolute and relative paths; pathname generally suggests an absolute path.
The filesystem can be arbitrarily deep. However, each component of a pathname must have a name no more than 255