《Understanding the Linux kernel》学习笔记 Chapter 12: The Virtual Filesystem

    xiaoxiao2021-03-25  110

    Linux manages to support multiple filesystem types in the same way other Unix variants do, through a concept called the Virtual Filesystem.

    The idea behind the Virtual Filesystem is to put a wide range of information in the kernel to represent many different types of filesystems; there is a field or function to support each operation provided by all real filesystems supported by Linux.

    12.1 The Role of the Virtual Filesystem (VFS)

    The Virtual Filesystem (also known as Virtual Filesystem Switch or VFS) is a kernel software layer that handles all system calls related to a standard Unix filesystem. Its main strenght is providing a common interface to several kinds of filesystems.

    Filesystems supported by the VFS may grouped into three main classes: Disk-based filesystems, Network filesystems, Special filesystems.

    Unix directories build a tree whose root is the / directory. The root directory is contained in the root filesystem, which in Linux, is usually of type Ext2 or Ext3. All other filesystems can be "mounted" on subdirectories of the root filesystem.

    12.2.1 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 concerning 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 (that is, a particular name of the file) with the corresponding file. The most recently used dentry objects are contained in a disk cache named the dentry cache, which speeds up the translation from a file pathname to the inode of the last pathname component.

    12.2.2 System Calls Handled by the VFS

    12.2 VFS Data Structures

    12.2.1 Superblock Objects

    12.2.2 Inode Objects

    All information needed by the filesystem to handle a file is included in a data structure called an inode. A filename is a casually assigned label that can be changed, but the inode is unique to the file and remains the same as long as the file exists.

    12.2.3 File Objects

    A file object describes how a process interacts with a file it has opened. The object is created when the file is opened and consists of a file structure.

    12.2.4 dentry Objects

    Once a directory entry is read into memory, it is transformed by the VFS into a dentry object based on the dentry structure.

    The kernel creates a dentry object for every component of a pathname that a process looks up; the dentry object associates the component to its corresponding inode.

    12.2.5 The dentry Cache

    To maximize efficiency in handling dentries, Linux uses a dentry cache, which consists of two kinds of data structures:

    A set of dentry objects in the in-use, unused, or negative state.A hash table to derive the dentry object associated with a given filename and a given directory quickly.

    12.2.6 Files Associated with a Process

    12.3 Filesystem Types

    12.3.1 Special Filesystems

    Special filesystemss 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.

    12.3.2 Filesystem Type Registration

    The VFS must keep track of all filesystem types whose code is currently included in the kernel.

    Each registered filesystem is represented as a file_system_type object.

    All filesystem-type objects are inserted into a singly linked list.

    12.4 Filesystem Handling

    Being a tree of directories, every filesystem has its own root directory. The directory on which a filesystem is mounted is called the mount point. A mounted filesystem is a child of the mounted filesystem to which the mount point directory belongs.

    12.4.1 Namespaces

    Every process might have its own tree of mounted filesystems -- the so-called namespace of the process.

    A process gets a new namespace if it is created by the clone() system call with the CLONE_NEWS flag set.

    When a process mount -- or unmounts -- a filesystem, it only modifies its namespace.

    The namespace of a process is represented by a namespace structure pointed to by the namespace field of the process descriptor.

    12.4.2 Filesystem Mounting

    Linux is possible to mount the same filesystem several times.

    12.4.3 Mounting a Generic Filesystem

    12.4.4 Mounting the Root Filesystem

    Linux kernel allows the root filesystem to be stored in many different places.

    Mounting the root filesystem is a two-stage procedure, shown in the following list:

    The kernel mounts the special rootfs filesystem, which simply provides an empty directory that serves as initial mount point.The kernel mounts the real root filesystem over the empty directory.

    12.4.5 Unmounting a Filesystem

    12.5 Pathname Lookup

    12.5.1 Standard Pathname Lookup

    12.5.2 Parent Pathname Lookup

    12.5.3 Lookup of Symbolic Links

    12.6 Implementations of VFS System Calls

    12.6.1 The open() System Call

    The open() system call is serviced by the sys_open() function, which receives as its parameters the pathnamefilename of the file to be opened, some access mode flags flags, and a permission bit maskmode if the file must be created.

    12.6.2 The read() and write() System Calls

    12.6.3 The close() System Call

    12.7 File Locking

    12.7.1 Linux File Locking

    12.7.2 File-Locking Data Structures

    12.7.3 FL_FLOCK Locks

    12.7.4 FL_POSIX Locks

    转载请注明原文地址: https://ju.6miu.com/read-5181.html

    最新回复(0)