Understanding Linux Virtual File System VFS-Overview

Currently, in addition to the Linux standard file system ext2/ext3/ext4, there are many file systems, such as reiserfs, XFS, Windows vfat NTFS, network File System NFS and FLASH file system jffs2, yaffs/yaffs2 ubifs. Linux provides perfect support through the intermediate layer called VFS.

For users, these file systems are almost transparent. In most cases, users do not need to care about the underlying file system implementation through the VFS interaction between libc and kernel, however, sometimes applications also need to consider the underlying File System Restrictions (for example, fat vfat does not support connections, for example, each file system supports different maximum file limits ).

Significance of VFS

1. Provide a standard file operation interface to the application layer;

2. provides a flexible interface for the file system to facilitate the migration of file systems of other operating systems to Linux;

3. VFS uses a series of efficient management mechanisms, such as inode cache, dentry cache, and file system pre-reading technologies, so that the underlying file system can achieve high performance without having to indulge in complex Kernel operations;

4. In addition, VFS abstracts some complex operations into VFS as much as possible to simplify the implementation of the underlying file system.

VFS Architecture

File System category

File systems can be divided into the following types

1. Disk File System

The maximum number of such file systems is ext2/ext3/ext4, XFS of SGI, and Flash file systems such as jffs2 yaffs ubifs; crasmfs squashfs and other read-only file systems; fat VFA NTFs and other Windows file systems;

Most of these file systems are block-based file systems. The data and metadata of file systems are stored on Block devices. Flash file systems are slightly different. Flash file systems are located on MTD,

Flash file systems must deal with complex functions such as bad processing, garbage collection, and wear balancing. F With the popularization of SD/mmccard and the inherent shortcomings in the scalability and startup speed of FLASH file systems. The Flash file system has gradually exited the Embedded Stage.

Cramfs squashfs is simple, efficient, and stable. It is still used in file system read-only scenarios. The two features are read-only and compressed. The complexity of a file system comes from writing data, deleting data, truncate operations, and adding or deleting directories. Therefore, a read-only file system is much simpler than a readable/writable file system. The most intuitive method is to view the implementation code of the cramfs file system. There are only two small files in the partition.

Reiserfs puts forward many new concepts of file systems, and greatly optimizes the read and write operations on small files. Of course, there are too many new concepts, which are also the cause of poor readability. In addition, because the author of reiserfs, Hans reiserfs, was convicted of killing his wife, the development of reiserfs was also affected.

XFS is quite complex. I will analyze it separately later.

2. Special file systems

Such file systems are also very common. They do not provide regular file storage and access. file systems are built on memory and provide special file system functions. Such as proc file system, pipe file system, and tmpfs

3. Network File System

Including network file systems such as NFS coda AFS

General file Model

VFS provides abstraction for underlying file systems in two ways.

1. Provide a minimum general model that supports the minimum intersection of all file systems.

2. Provide a general model as big as possible so that this model contains a collection of all file system functions.

Linux uses the second policy to implement VFS. Therefore, VFS encapsulates all the functions and abstractions of the underlying file system, and VFS forwards application-layer requests to specific file systems.

When processing files, the application space and kernel space use different objects. For applications, the file descriptor is used to represent a file. This file descriptor is an integer allocated to the file by the kernel when the file is opened. Note that this file descriptor is valid only in this process; for the kernel, an inode is used to represent a file. This inode may correspond to multiple file descriptors in multiple processes at the application layer.

Inode

Each file or directory in the kernel has an inode, which consists of two main parts:

1. metadata describing the File status. The file metadata includes the file size, permission, type, and time;

2. Description of the file data, which is used to define the storage location of the file data on the disk.

Inode is only a representation of files in the kernel memory. Although each file has an inode, not every file has a corresponding disk inode on the disk. In fact, some file systems do not have disk inode, inode generation sometimes requires file system scanning.

Link

Links are UNIX-specific concepts and can be divided into soft links and hard links.

A soft link is also called a symbolic link. The content of a soft link file points to a file path, that is, the actual location of the file. The soft link can also point to a soft link.

Two files share the same inode,

Not all file systems support symbolic links and hard links. For example, file systems such as fat and yaffs do not support symbolic links. In general, file systems without a disk directory structure certainly do not support hard links, but those without disk inode certainly do not.

Although hardware and software links bring a lot of convenience to Linux/Unix operation management, they often introduce a lot of complexity in many software implementations.

VFS object type

The common VFS model contains the following types of objects:

1. Super Block

Stores information about the file system. For the disk file system, this object usually corresponds to a file system control block (Disk super block) on the disk)

2. inode

Stores information related to a file. For a disk file system, this object usually corresponds to a file control block (Disk inode) on the disk ). Each inode corresponds to a number that uniquely identifies the file in the file system.

3. File

File is related to processes. File represents an open file. The relationship between file and inode is many-to-one, because multiple processes can open the same file, the system creates a file structure for each open operation.

4. dentry

Many operations on the underlying file system are heavily dependent on the inode of the file. Before file operations, we need to find the inode corresponding to the file according to the path name. We know that the file system is a tree structure, so we need to find the file or directory to be operated from the root directory through the directory tree. This traversal process involves disk operations, which is very time-consuming. According to the locality principle, it is necessary to cache the search process. dentry is to speed up the data structure introduced by directory traversal.

Each disk-based file system has a specific method to build a directory tree. Generally, there are two methods:

1. Directory items are saved on the disk

2. Rebuild the directory item through the parent-child relationship of the Disk File