Linux VFS kernel data structure

<strong> Simple Summary: FD is just an integer that is generated when open. As an index, the process uses the file descriptor in the PCB to find the file pointer Filp that the FD points to. </strong>

The operation of the file descriptor (for example: Open) returns a file descriptor, which maintains a file descriptor table in each process space, and all open files are referenced by the file descriptor in this form;
The stream (for example: fopen) Returns a file structure pointer that contains a document descriptor, which can be considered as encapsulation of the system call to the FD direct operation, with the advantage of having an I/O cache

Linux supports a wide variety of file system formats, such as Ext2, Ext3, ReiserFS, FAT, NTFS, iso9660, and so on, and different disk partitions, CDs, or other storage devices have different file system formats, but these file systems can be mount to a directory, Let us see a unified directory tree, directories and files on various file systems we use the LS command to look the same, read and write operations are the same, how is this done? The Linux kernel makes an abstraction layer on a variety of file system formats, making the concepts of files, directories, read-write access, and so on, an abstraction layer, so that the various file systems look the same, and this abstraction layer is called the virtual file system (Vfs,virtual Filesystem). In the previous section we described a typical file system storage layout on disk, which we described in the kernel of the runtime file system.
3.1. Kernel data structure

The VFS subsystem of the Linux kernel can be illustrated as follows:
<a href= "Http://www.emacsvi.com/wp-content/uploads/2015/10/linux_vfs1.png" ></a>

<strong> Each process holds a file descriptor table in the PCB (Process Control block), which is an index to the list, and each table entry in the File description table has a pointer to the open file. Now let's be clear: The opened file is represented in the kernel with the file struct, and the pointer in the document descriptor table points to the file structure body. </strong>

Maintains the file Status Flag (member f_flags of the file struct) and the current read and write location in the file structure (member F_pos of the file struct). In, Process 1 and Process 2 both open the same file, but correspond to different file structure bodies, so you can have different file Status flags and read and write locations. The more important members of the file struct are the F_count, which represents the reference count (Reference count), which we'll talk about, which will cause multiple file descriptors to point to the same document struct, such as DUP, fork, and so on. For example, FD1 and FD2 both refer to the same file struct, then its reference count is 2, when close (FD1) does not release the file structure, but only the reference count to 1, if close (FD2), the reference count will be reduced to 0 while releasing the file structure, This really closed the file.

Each file struct points to a file_operations struct, the members of which are function pointers to kernel functions that implement various file operations. For example, in the user program read a file descriptor, read through the system call into the kernel, and then find the file descriptor pointed to the document structure, to find the structure of the file_operations, which is pointed to the body, Invokes the kernel function pointed to by its read member to complete the user request. In the user program calls Lseek, read, write, IOCTL, open and other functions, and ultimately by the kernel calls file_operations the members of the kernel function point to complete the user request. The release member in the File_operations struct is used to complete the close request of the user program, which is called release instead of close because it does not necessarily close the file, but reduces the reference count, and only the reference count is reduced to 0 to close the file. For regular files that are open on the same file system, the steps and methods for file operations such as read, write, and so on, should be the same, and the calling function should be the same, so the file structure of the three open files in the diagram points to the same file_operations struct. If you open a character device file, then its read, write operation must be different from the regular file, not read and write disk data block, but read and write hardware devices, so the file structure should point to the various file_operations structure body, The various file manipulation functions are implemented by the driver of the device.

Each file struct has a pointer to the dentry struct, and "Dentry" is an abbreviation for the directory entry (directory entry). The arguments we pass to the open, stat, and other functions are a path, such as/home/akaedu/a, where the inode of the file needs to be found based on the path. To reduce the number of reads, the kernel caches the tree structure of the directory, called the Dentry cache, where each node is a dentry struct, as long as the dentry is searched along the parts of the path, from the root directory/to the home directory, then to the akaedu directory, and then to the file a. Dentry cache saves only recently accessed directory entries, and if the directory entry you are looking for is not in the cache, it will be read from disk to memory.

Each dentry struct has a pointer pointing to the INODE structure. The INODE structure holds the information read from the disk inode. In the example, there are two dentry, representing/home/akaedu/a and/home/akaedu/b, each pointing to the same inode, stating that the two files are mutually hard links. The inode structure holds information that is read from the inode in the partition, such as owner, file size, file type, and permission bit. Each inode struct has a pointer to the inode_operations struct, which is a set of function pointers that point to some kernel functions that complete the file directory operation. Unlike File_operations, inode_operations points to a function that does not operate on a file, but functions that affect the layout of files and directories, such as adding deleted files and directories, tracking symbolic links, and so on. Each inode structure that belongs to the same file system can point to the same inode_operations struct.

The inode struct has a pointer to the Super_block struct. The Super_block structure holds information that is read from a super block on a disk partition, such as file system type, block size, and so on. The S_root member of the Super_block struct is a pointer to Dentry, indicating where the root directory of the filesystem is being mount, in which case the partition is mount to the/home directory.

The structure of file, Dentry, inode and Super_block constitute the core concept of VFS. For ext2 file systems, there is also the concept of inode and Super block on disk storage layouts, so it is easy to establish correspondence with the concepts in VFS. Other file system formats from non-UNIX systems (such as Windows FAT32, NTFS), may not have inode or Super block concept, but in order to mount to the Linux system, but also in the driver hard to gather, Looking at FAT32 and NTFS partitions under Linux will find that the permission bits are wrong, and all files are rwxrwxrwx, because they do not have the concept of inode and permission bit, which is hard to come out of.

Linux VFS kernel data structure