Down Tour (18): Virtual file System (ii)

　Catalog Item Object

　　VFS treats the directory as a file, so in Path/bin/vi, bin and VI belong to the file--bin is a special directory file and VI is an ordinary file. Each component in the path is represented by an index node object. Although they can be uniformly represented by an index node, VFS often needs to perform directory-related operations, such as path name lookups. The path name lookup needs to parse every component of the path, not only to make sure it is valid, but also to look for the next part of the path further.

To facilitate the search operation. VFS introduces the concept of catalog items. Each dentry represents a specific part of the path, and for the previous example,/, bin, and VI belong to the Catalog item object. The first two are directories, and the last one is the normal file. It's important to be clear: in the path, including the normal file, each part is a catalog item object.

Catalog items can also include installation points. In Path/mnt/cdrom/foo,/, MNT, CDROM, and Foo are all part of the Catalog item object. The VFS creates catalog item objects on-site, if needed, when performing directory operations. The catalog item object is represented by the dentry struct:

Unlike the previous two objects, the Catalog item object does not have a corresponding disk data structure, and the VFS creates it in the field based on the path name in the string. And because the Catalog item object is not actually saved on disk, the directory item structure has no flags to be modified (that is, whether it is dirty or whether it needs to write back to the disk's flag).

　　Catalog Item Status

The catalog item object is made up of three valid states: used, unused, and negative.

A used directory entry corresponds to a valid index node that, when in use, means that it is being used by the VFS and points to the mailbox's index node and therefore cannot be discarded.

An unused catalog item corresponds to a valid index node, but it should indicate that the VFS is not currently using it, that the directory item object still points to a valid object, and is kept in the cache for use when needed. If you need to reclaim memory, you can destroy unused directory entries.

A negative state of a directory entry does not have a valid index node for the index node, or the path is not correct, but the directory entry remains so that the subsequent path query can be resolved quickly. If necessary, you can destroy it. After the catalog item object is released, it can also be saved in the Slab object cache. At this point, no VFS or file system code has a valid reference to the Catalog item object.

　　Catalog Item Cache

This is a very laborious task if the VFS layer iterates through all the elements in the pathname and resolves them to a directory item object one after the other. So the kernel caches the catalog item objects in the Catalog item cache (Dcache), which consists of three parts:

1. "Used" Catalog Necklace list. The linked list links The associated index nodes through the I_dentry link in the Index node object. Because a given index node may have multiple links, there may be more than one catalog item object, so a linked list is used to link them.

2. "Recently used" doubly linked list. The list contains the unused and negative state of the catalog item object.

3. A hash table and the corresponding three-column function are used to quickly parse a given path into a related catalog item object.

　　Catalog Item Operations

　　The dentry_operations struct indicates all the methods of the VFS operation directory entry:

　File Object

　　The last primary object of the VFS when the file object. The file object represents a file that the process has opened. If you stand in user space to look at the VFS, the file objects will first enter our horizons. The process is processed directly after the file, not the Super block, index node, or directory entry.

A file object is an in-memory representation of an open file. The object (not the physical file) is created by the corresponding open () system call and destroyed by the close () system call. All these file-related calls are actually the methods defined in the File action table. Because multiple processes can open or manipulate the same file at the same time, there may be multiple corresponding file objects for the same file. The file object represents the open file only in the process view, which in turn points to the Directory item object (which in turn points to the index node), in fact only the Catalog item object represents the actual file that was opened. Although the file object corresponding to a file is not unique, the corresponding index node and directory item object are unique. The file object has the following structure:

Similar to the Catalog item object, the file object does not actually have the corresponding disk data. So there is no flag in the struct that indicates whether the object is dirty or if it needs to be written back to disk. The file object points to the related Catalog item object through the F_dentry pointer. The catalog item points to the associated index node, and the index node logs whether the file is dirty.

　File operations

The operation of the file object is represented by the file_operations structure, with the following structure:

　　Data structures related to file systems

　　In addition to the above-mentioned VFS base objects, the kernel uses additional standard data structures to manage other data related to the file system. The first struct is File_system_type, which describes a variety of specific file system types, such as ext3 or XFS. The second struct is Vfsmount, which is used to describe an instance of an installation file system.

Because Linux supports many different file systems, the kernel must have a special structure that describes the functionality and behavior of each file system. The structure is as follows:

The GET_SB () function reads the super block from disk and assembles the Super block object in memory when the file system is installed. The remaining functions describe the properties of the file system.

When the file system is actually installed, a VFSMOUNT structure is created at the mount point. The struct is used to represent an instance of a file system-that is, a mount point. The concrete structure is as follows:

Clearing the relationship between the file system and all other installation points is the most complex work in maintaining all of the installation point lists. So the various linked lists maintained in the VFSMOUNT structure are designed to be able to track these relationship information.

The Vfsmount structure also holds the flag information specified at installation time, which is stored in the mnt_flags domain.

These flags are useful when installing mobile devices that are not fully trusted by administrators.

　　and process-related data structures

Each process in the system has its own set of open files, such as the root file system, the current working directory, the installation point, and so on. There are three data structures that closely link the VFS layer with the process of the system. They are: Files_struct, fs_struct, and namespace structures.

The files_struct struct is pointed to by the files domain of the process descriptor. All information related to each process, such as open files and file descriptors, is included in the structure and description of the following:

The FD array pointer points to the open list of file objects, because Nr_open_default equals 32, so it can hold 32 file objects, and when the process opens more than 32 files, a new array is created, which, in order to optimize performance, can be appropriately increased nr_open_ The predefined value of default.

The second structure associated with a process is fs_struct. The structure is pointed to by the FS domain of the process descriptor. It contains file system and process-related information. The structure is as follows:

The structure contains the current working directory (PWD) and root directory of the current process.

The last struct is namespace, which is directed by the namespace domain of the process. After the 2.4 kernel, a single process namespace is added to the kernel, and it is the only installation file system that each process sees in the system-not only the root directory, but also the unique filesystem hierarchy. The structure is as follows:

　　

By default, all processes share the same namespace (that is, they see the same file system hierarchy from the same Mount table).

Linux supports quite a few types of files, from the local file system to the network file system, Linux has more than 50 file systems supported in the standard kernel. The VFS layer provides a unified implementation framework for these different file systems, and also provides a unified interface to work with standard system calls. Makes it easy to implement new file systems on Linux, which makes it easy for these filesystems to work together through standard UNIX system calls.

Reference from: "Linux Kernel Development".

Down Tour (18): Virtual file System (ii)