- 1 The Role of the Virtual Filesystem (VFS)
- 2 VFS Data Structures
- 3 Filesystem Types
- 4 Filesystem Handling
- 5 Pathname Lookup
- 6 Implementations of VFS System Calls
- 7 File Locking
The Virtual Filesystem is a kernel software layer that handles all system calls related to a standard Unix filesystem. Its main strength is providing a common interface to several kinds of filesystems.
Filesystems supported by the VFS may be grouped into three main classes:
- Disk-based filesystems
These manage storage space available in a local disk or in some other device that emulates a disk (such as a USB flash drive).
- Network filesystems
These allow easy access to files included in filesystems belonging to other networked computers.
- Special filesystems
These do not manage disk space, either locally or remotely.
The key idea behind the VFS consists of introducing a common file model capable of representing all supported filesystems.
The common file model consists of the following object types:
- The superblock object
- The inode object
- The file object
- The dentry object
Figure 12-2 illustrates with a simple example how processes interact with files. Three different processes have opened the same file, two of them using the same hard link. In this case, each of the three processes uses its own file object, while only two dentry objects are required—one for each hard link. Both dentry objects refer to the same inode object, which identifies the superblock object and, together with the latter, the common disk file.
A superblock object consists of a super_block structure.
While network and disk-based filesystems enable the user to handle information stored outside the kernel, special filesystems may provide an easy way for system programs and administrators to manipulate the data structures of the kernel and to implement special features of the operating system. Table 12-8 lists the most common special filesystems used in Linux; for each of them, the table reports its suggested mount point and a short description.
Every process might have its own tree of mounted filesystems—the socalled namespace of the process.
The POSIX standard requires a file-locking mechanism based on the
fcntl()system call. It is possible to lock an arbitrary region of a file (even a single byte) or to lock the whole file (including data appended in the future). Because a process can choose to lock only a part of a file, it can also hold multiple locks on different parts of the file.