<linux Kernel source > file system VFS Core 4.0. Version 4 basic concept source code

Aside from: The Linux kernel from 2.x and 3.x to now the latest 4.x changes very large, the most intuitive expression is that many of the book's kernel code has been unable to continue to use directly, so look at the new source is very meaningful!

(The kernel source code below is from the kernel 4.0.4 version, I have verified the correct, the text assumes that the reader on the Linux system Mount command has operational experience.) In addition, the Linux kernel source code on the file operation of more than the amount of memory management or device management more than an order of magnitude, so want to make every place completely clear is far away from my ability. The meaning of this article is to help build up a hierarchical model of super blocks, indexes, and catalogs. In the following code I try to retain the source of the English comments, and then for the more important part of the translation notes)

A. VFS (Virtual file system) handles the most basic data structures for file systems Mount---Vfsmount

Vfsmount the function of this struct is not discussed in depth, but it must be clear that each filesystem has one such structure. The first thing you have to know is what this struct is for, and when the file system is going to be mounted, it is the corresponding vfsmount struct that is added to the kernel in a global list---the mount_hashtable array list. Mount_hashtable is the array, each member is a hash linked list, for example, when the file search, traversing to a "special directory" (such as a USB stick mounted directory), will be found from the mount_table corresponding list head, The entire hash list is then traversed until the corresponding vfsmount structure is found, and the directory structure of the special directory Dentry (detailed below) is replaced to make it the root of the new file system. The following is the VFSMOUNT structure:

(Some older vfsmount struct members have more than 10 definitions but there are only 3 members left)

View Code

Two. File system "The three great Elders"

(1) Super_block Super block

The Super block represents the entire file system itself, generally speaking, the Super block and Vfsmount, although the same as the entire file system one by one corresponding to the relationship, but Super_block is responsible for the control of the part, and Vfsmount is simply a mount aspect. These in the later file operations in detail, the Super block and the following to say the index node and directory nodes are using C language to implement object-oriented programming, using a struct as a virtual table in C + + or Java interface. The super block structure holds the size of the file block set by the file system, the operation function of the Super block, and all the index nodes in the entire file system. The control of different file systems contains different control information, and the super_block structure preserves the structure information we need. Each member of the SUPER_BLOCK structure is recommended to understand rather than memorize, one is easy to forget, and the other is that the version iteration is too fast, unless, of course, the job requires ~

View Code

Attached: File_system_type structure, can skip

View Code

(2) Directory node Dentry

　　File systems are generally managed in a tree-like structure, and the directory is the most intuitive expression, all the catalogs layer by layer, and eventually converge to the root directory. For this tree structure is organized with dentry structure. As in Linux, the directory itself is also a special file. Each file is a dentry, and this dentry is recursively linked to the upper layer until the root directory. To speed up the search, the kernel also uses a hash table to cache dentry, known as the Dentry cache, which is used very frequently, because it is often necessary to continue to work on the same file repeatedly, If you need to do a search in the file system for each operation, the time cost is very high, so most of the traversal lookup dentry before the Dentry cache to find.

View Code

(3) Index node object inode

　　The most significant difference between an index node object and a directory node object is that a directory node object refers to a file in a logical sense, whereas an index node object refers to a physical file, and the directory item does not have an image corresponding to it on disk, and each of the index nodes has a corresponding image on disk. The inode represents a file, the inode holds the size of the file, the creation time, the size of the file's block, and so on, because the path to the file can have multiple (such as the files produced by the LN command), and the inode has only one! The inode structure and the file system are irrelevant, and the inode exists throughout the life of the file, and it contains the data maintained on the disk.

View Code

Three. File objects in the kernel

This struct is actually not associated with the VFS architecture, except that the file objects in the Linux kernel, each time a file is opened, creates an associated file structure in the kernel and passes it to any function that operates on the file. After all instances of the file have been freed, file structures in the kernel are freed.

View Code

Summarize and generalize:

(1) Vfsmount,super_block,dentry,inode structure in the kernel there is a global hash table cache to speed up access, each hash array with a hash list of the same kind of node type in the same linked list, A member variable is specifically set to access the node adjacent to it in the hash list.

(2) file and dentry are more logical, Super_block and inode are more physical in meaning.

(3) Finally presented a picture, personally think is a summary of the Linux file system structure of the most comprehensive picture

<linux Kernel source > file system VFS Core 4.0. Version 4 basic concept source code