Virtual File System
The Role of Virtual Filesystem (VFS)
Linux manages to support multiple filesystem types in the same way other Unix variants do, through a concept called the Virtual Filesystem.
The Virtual Filesystem (VFS) 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 serveral kinds of filesystems. The VFS is an abstraction layer between the application program and the filesystem implementation.
Filesystems supported by the VFS may be grouped into three main classes:
- Disk-based filesystems: these manage memory space available in a local disk or in some other device that emulates a disk.
- 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 Common File Model
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: stores information concering a mounted filesystem.
- The inode object: stores general information about a specific file.
- The file object: stores information about the interaction between an open file and a process.
- The dentry object: stores information about the linking of a directory entry with the corresponding file.
A disk cache is a software mechanism that allows the kernel to keep in RAM some information that is normally stored on a disk, so that further access to that data can be quickly satisfied without a slow access to the disk itself.
VFS Data Structures
A superblock object consists of a super_block structure. All superblock objects are linked in a circular doubly linked list.
The methods associated with a superblock are called superblock operations. They are described by the super_operations structure whose address is inlcluded in _s_op field.
All information needed by the filesystem to handle a file is included in a data structure called inode. Each inode object always apears in one of the following circular doubly linked lists:
- The list of valid unused inodes
- The list of in-use inodes
- The list of dirty inodes.
The inode objects are also included in a hash table named inode_hashtable. The methods associated with an inode object are called inode operations.
A file object describes how a process interacts with a file it has opened.
Notice that file objects have no corresponding image on disk, and hence no “dirty” field is included in the file structure to specify that the file object has been modified.
The main information stored in a file object is the file pointer - the current position in the file from which the next operation will take place. Because several processes may access the same file concurrently, the file pointer must be kept in the file object rather than the inode object.
Each filesystem includes its own set of file operations that perform such activities as reading and writing a file. When the kernel loads an inode into memory from disk, it stores a pointer to these file operations in a file_operations structure whose address is containd in the i_fop field of the inode object. When a process opens the file, the VFS initializes the f_op field of the new file object with the address stored in the inode so that further calls to file operations can use these functions. If necessary, the VFS may later modify the set of file operations by storing a new value in f_op.
Once a directory entry is read into memory, it is transformed by the VFS into a dentry object based on the dentry structure.
Notice that dentry objects have no corresponding image on disk, and hence no field is included in the dentry structure to specify that the object has been modified.
Each dentry object may be in one of four states:
- In use
The dentry Cache
Because reading a directory entry from disk and constructing the corresponding dentry object requires considerable time, it makes sense to keep in memory dentry objects that you’ve finished with but might need later.
Files Associated with a Process
A whole data structure of type fs_struct is used for representing the interactions between a process and a filesystem, and each process descriptor has an fs filed that points to the process fs_struct structure.
A table, whose address is contained in the files field fo the process descriptor, specifies which files are currently opened by the process, with files_struct 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 ther kernel and to implement special features of the operating system.
The kernel assigns to each mounted special filesystem a fictitious block device that has the value 0 as major number and an arbitrary value (different for each special filesystem) as a monor number.