1.8. Files and File Systems
Solaris provides facilities for storage and management of data, as illustrated in Figure 1.7. A file provides a container for data, a directory contains a number of files, and a file system implements files and directories upon a device, typically a storage medium of some type.
Figure 1.7. Files Organized in a Hierarchy of Directories
A file system can be mounted on a branch of an existing file system to extend the hierarchy. The hierarchy hides the mount so that it is transparent to users or applications that traverse the tree.
Solaris implements several different types of files:
Special files represent a device driver. Reads and writes to special files are handled by a device driver and translated into I/O of some type.
Pipes are a special type of file that do not hold data but can be opened by two different processes so that data can be passed between them.
Hard links link to the data of other files within the same file system. With hard links, the same data can have two different file names in the file system.
Symbolic links point to other path names on any file system.
Sockets in the file system enable local communication between two processes.
1.8.1. File Descriptors and File System Calls
Processes interface with files through file-related system calls. The file-related system calls identify files by two means: their path name in the file system and a file descriptor. A file descriptor is an integer number identifying an open file within a process. Each process has a table of open files, starting at file descriptor 0 and progressing upward as more files are opened. A file descriptor can be obtained with the open() system call, which opens a file named by a path name and returns a file descriptor identifying the open file.
fd = open("/etc/passwd",flag, mode);
Once a file has been opened, a file descriptor can be used for operations on the file. The read(2) and write(2) operations provide basic file I/O, along with several other advanced mechanisms for performing more complex operations. A file descriptor is eventually closed by the close(2) system call or by the process's exit. By default, file descriptors 0, 1, and 2 are opened automatically by the C runtime library and represent the standard input, standard output, and standard error streams for a process.
1.8.2. The Virtual File System Framework
Solaris provides a framework under which multiple file system types are implemented: the virtual file system framework. Earlier implementations of UNIX used a single file system type for all of the mounted file systems; typically, the UFS file system from BSD UNIX. The virtual file system framework, developed to enable the network file system (NFS) to coexist with the UFS file system in SunOS 2.0, became a standard part of System V in SVR4 and Solaris.
Each file system provides file abstractions in the standard hierarchical manner, providing standard file access interfaces even if the underlying file system implementation varies. The file system framework allows almost any objects to be abstracted as files and file systems. Some file systems store file data on storage-based media, whereas other implementations abstract objects other than storage as files. For example, the procfs file system abstracts the process tree, where each file in the file system represents a process in the process tree. We can categorize Solaris file systems into the following groups:
Storage Based — Regular file systems that provide facilities for persistent storage and management of data. The Solaris UFS and PC/DOS file systems are examples.
Network File Systems — File systems that provide files which appear to be in a local directory structure but are stored on a remote network server; for example, Sun's network file system (NFS).
Pseudo File Systems — File systems that present various abstractions as files in a file system. The /proc pseudo file system represents the address space of a process as a series of files.
The framework provides a single set of well-defined interfaces that are file system independent; the implementation details of each file system are hidden behind these interfaces. Two key objects represent these interfaces: the virtual file, or vnode, and the virtual file system, or vfs objects. The vnode interfaces implement file-related functions, and the vfs interfaces implement file system management functions. The vnode and vfs interfaces call appropriate file system functions depending on the type of file system being operated on. Figure 1.8 shows the file system layers. File-related functions are initiated through a system call or from another kernel subsystem and are directed to the appropriate file system via the vnode/vfs layer.
Figure 1.8. VFS/Vnode Architecture
Table 1-2 summarizes the major file system types that are implemented in Solaris.