Link between file descriptor, File descriptor table, open file tables, directory entries, index nodes

The connection between the file descriptor, File descriptor table, open file tables, directory entries, and index nodes is as follows:

Each process in the PCB (process Control Block) has a File descriptor table, the file descriptor is the index, each table item has a pointer to the open file, the open file in the kernel with the document structure, The pointer in the file descriptor table points to the file structure body.

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 also F_count, which represents the reference count (Reference count). System calls such as DUP, fork, and so on can cause multiple file descriptors to point to the same document struct, for example, Fd1 and fd2 refer to the same file struct, so its reference count is 2, and when Close (FD1) does not release the file struct, it simply cuts the reference count to 1. If Close (FD2) again, the reference count will be reduced to 0 and the file structure is released, which really closes the files.

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 parameters of 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.

Link between file descriptor, File descriptor table, open file tables, directory entries, index nodes