In-Depth Analysis of the Linux Virtual File System (VFS)

1 Overview and Historical Background of Linux VFS

The Linux Virtual File System (VFS) is an extremely important subsystem within the Linux kernel. It serves as an abstraction layer for file systems, providing a unified file access interface for user-space applications while offering a standardized implementation framework for various specific file systems supported by the kernel, such as ext4, XFS, and Btrfs.The essence of VFS is a software mechanism that defines common interfaces and data structures, shielding the specific implementation details of different file systems. This allows applications to use the same system calls (such as open, read, write, and close) to access any type of file system, regardless of whether these file systems are stored on local disks, network storage, or in memory.

The historical evolution of VFS is closely related to the development of the Linux operating system. Early Unix systems typically supported only a single type of file system, which led to the file system structure being deeply embedded in the system kernel, limiting the system’s flexibility and scalability. As Linux evolved, the demand for support for multiple file systems grew, prompting Linux to adopt modern operating system design concepts by introducing the VFS abstraction layer between the system kernel and specific file systems. This design enables Linux to support dozens of file systems simultaneously, from traditional ext2/ext3 to modern flash file systems (such as F2FS), network file systems (such as NFS and CIFS), and even some special pseudo file systems (such as procfs and sysfs).

The design philosophy of VFS is primarily reflected in several aspects: First, it follows the Unix philosophy of “everything is a file,” where not only regular files and directories are treated as files, but also devices, sockets, pipes, etc., are abstracted as files, providing a unified access method. Second, VFS adopts an object-oriented design philosophy; although implemented in C (which lacks direct object-oriented syntax support), it achieves polymorphism by including function pointers within structures, allowing different file systems to have their specific implementation methods.

Table: Comparison of Major File System Types Supported by Linux

File System Type	Characteristics	Applicable Scenarios
ext4	Stable and reliable, good compatibility, journaling file system	General Linux systems, standard workloads
XFS	High performance, supports large files and large capacity storage	Enterprise applications, big data processing
Btrfs	Copy-on-write, supports snapshots and data checksums	Desktops and servers requiring advanced features
F2FS	Optimized for flash storage	SSD storage, mobile devices
NFS	Network file system	Network sharing, distributed environments
procfs	Pseudo file system providing process and system information	System monitoring and debugging

The position of VFS in the Linux architecture can be described using a layered model. At the top layer are user-space applications that interact with the kernel through system call interfaces. In the middle is the VFS layer, which provides an abstract interface for file operations. At the bottom layer are various specific file system implementations that interact with block device drivers to ultimately access physical storage media. This layered architecture makes the Linux file system both flexible and efficient, allowing new file systems to be easily added to the kernel without modifying upper-layer applications or the VFS interface.

2 Core Data Structures and Relationships of VFS

To deeply understand how Linux VFS works, one must grasp its four core data structures: super block, inode, dentry, and file. These data structures together form the backbone of VFS, defining the static structure and dynamic behavior of file systems. Although the implementation details of these concepts may vary in specific file systems, VFS enforces a unified interface for them, achieving abstraction and unified management of file systems.

2.1 Super Block (super_block)

The super block is the highest-level data structure in VFS, representing an instance of a mounted file system and storing the file system’s metadata and control information. Each mounted file system has a super block object in memory, whether the file system is disk-based (like ext4) or memory-based (like tmpfs). The super block serves as the “identity card” of the file system, recording its basic characteristics and operational set.

The core data structure of the super block struct super_block is defined in the kernel and contains the following key fields:

struct super_block {<br />    struct list_head s_list;                 /* Pointer to the super block list */<br />    dev_t s_dev;                             /* Device identifier */<br />    unsigned long s_blocksize;               /* Block size */<br />    unsigned char s_blocksize_bits;          /* Bit representation of block size */<br />    struct file_system_type *s_type;         /* File system type */<br />    struct super_operations *s_op;           /* Super block operation table */<br />    struct dentry *s_root;                   /* Directory entry of the mount point */<br />    struct list_head s_inodes;               /* List of all inodes */<br />    struct list_head s_dentry_lru;           /* List of unused directory entries */<br />    void *s_fs_info;                         /* Private information of the specific file system */<br />};

Among them, struct super_operations is a set of function pointers that define operations for the super block, including allocating inodes, destroying inodes, and synchronizing the file system. These operations are implemented by specific file systems, and VFS manages the file system by calling these functions.

A metaphor in real life: If we compare a file system to a building, then the super block is like the architectural blueprint of the building. The blueprint records the basic information of the building (such as the number of floors, room layout, entrance and exit locations, etc.) and also defines the management rules of the building (such as cleaning processes, security inspections, etc.). Regardless of how the interior of the building is decorated, the management can understand the basic situation and management methods of the building through the blueprint.

2.2 Inode (inode)

The inode is the core data structure used in VFS to represent the metadata of files or directories. Each file or directory in VFS has a corresponding inode that records the object’s attribute information, such as file size, owner, permissions, timestamps (creation, modification, access time), and the location of data on the storage device. Notably, the inode does not store the name of the file or directory; the name information is stored in the directory entry.

The core data structure of the inode struct inode contains the following key fields:

struct inode {<br />    umode_t i_mode;                          /* File type and permissions */<br />    uid_t i_uid;                             /* Owner user ID */<br />    gid_t i_gid;                             /* Owner group ID */<br />    loff_t i_size;                           /* File size */<br />    struct timespec64 i_atime;               /* Last access time */<br />    struct timespec64 i_mtime;               /* Last modification time */<br />    struct timespec64 i_ctime;               /* Last status change time */<br />    const struct inode_operations *i_op;     /* Inode operation table */<br />    struct super_block *i_sb;                /* Associated super block */<br />    struct address_space *i_mapping;         /* Address space */<br />    unsigned long i_ino;                     /* Inode number */<br />    void *i_private;                         /* Private information of the specific file system */<br />};

The inode operation table struct inode_operations defines operations for the inode, such as creating files, creating directories, creating symbolic links, and deleting files. These operations are also implemented by specific file systems, and VFS calls these functions to operate on objects within the file system.

A metaphor in real life: The inode is like the ID card or file card of a document. In a large library, each book has a file card that records the basic information of the book (such as title, author, publisher, shelving time, and specific location in the library), but the file card itself does not contain the actual content of the book. Through the file card, the administrator can quickly find the physical location of the book without needing to know the specific content of the book.

2.3 Directory Entry (dentry)

The directory entry (dentry) is the data structure used in VFS to represent components of a path. Each component of a path (such as /home/user/file.txt which includes /, home, user, and file.txt) has a corresponding directory entry object. The main function of the directory entry is to associate the file path with the corresponding inode and construct a directory tree structure, thus supporting path lookup and file access.

Unlike super blocks and inodes, directory entries typically do not have corresponding disk structures; instead, they are created on-the-fly by VFS based on path names. Directory entry objects are cached in the dentry cache to speed up subsequent path lookup operations.

The core data structure of the directory entry struct dentry contains the following key fields:

struct dentry {<br />    struct dentry *d_parent;                 /* Parent directory entry */<br />    struct qstr d_name;                      /* Directory entry name */<br />    struct inode *d_inode;                   /* Associated inode */<br />    struct list_head d_child;                /* Sibling node list */<br />    struct list_head d_subdirs;              /* Child node list */<br />    struct dentry_operations *d_op;          /* Directory entry operation table */<br />    struct super_block *d_sb;                /* Associated super block */<br />    int d_flags;                             /* Directory entry flags */<br />    void *d_fsdata;                          /* Private information of the specific file system */<br />};

The directory entry operation table struct dentry_operations defines operations for directory entries, such as comparing file names, hash calculations, and releasing directory entries. These operations allow specific file systems to customize the behavior of directory entries.

A metaphor in real life: The directory entry is like the road signs and address system in a city. Each road sign at an intersection indicates different paths, while house numbers identify specific buildings. Through road signs and house numbers, people can find their destination step by step without needing to know the exact coordinates of the destination in advance. The directory entry cache is like a “cognitive map” in people’s minds, where frequently traveled routes are remembered, so there is no need to look at road signs again when searching next time.

2.4 File Object (file)

The file object (file) is the data structure in VFS that represents an opened file. Each time a process opens a file, VFS creates a file object that records the interaction information between the process and the opened file, such as the current read/write position, access mode (read, write, append, etc.), and operation function pointers. It is important to note that the file object represents the interaction session between the process and the file, not the file itself; thus, the same file may be opened by multiple processes, each having its independent file object.

The core data structure of the file object struct file contains the following key fields:

struct file {<br />    struct path f_path;                      /* File path */<br />    struct inode *f_inode;                   /* Associated inode */<br />    const struct file_operations *f_op;      /* File operation table */<br />    loff_t f_pos;                            /* Current read/write position */<br />    atomic_long_t f_count;                   /* Reference count */<br />    unsigned int f_flags;                    /* Open flags */<br />    fmode_t f_mode;                          /* File mode */<br />    void *private_data;                      /* Private data */<br />};

The file operation table struct file_operations is one of the most important operation tables in VFS, defining operations for files, such as opening, closing, reading, writing, and memory mapping. These function pointers are implemented by specific file systems or device drivers, and user-space system calls (such as read and write) ultimately call these functions.

A metaphor in real life: The file object is like a reading session of a book. When a person opens a book to read, they remember which page they are on (current read/write position), how they are reading (close reading, skimming, etc., corresponding to access mode), and how to turn the pages (operation functions). If multiple people are reading different copies of the same book simultaneously, each person has their reading progress and method, without interfering with each other. Closing the file is like closing the book, ending the reading session.

2.5 Relationships Among the Four Core Data Structures

Having understood the four core data structures of VFS, we need to clarify their relationships. These data structures do not exist in isolation; they are interrelated and together form the complete framework of VFS. The following diagram illustrates the logical relationships among these core data structures using Mermaid:

contains<br />contains<br />associated_with<br />referenced_by<br />referenced_by<br />1<br />1<br />1<br />1<br />1<br />*<br />*<br />*<br />*<br />*<br />super_block<br /><br />+struct list_head s_list<br /><br />+struct file_system_type *s_type<br /><br />+struct super_operations *s_op<br /><br />+struct dentry *s_root<br /><br />+struct list_head s_inodes<br /><br />+void *s_fs_info<br /><br />inode<br /><br />+umode_t i_mode<br /><br />+loff_t i_size<br /><br />+struct inode_operations *i_op<br /><br />+struct super_block *i_sb<br /><br />+unsigned long i_ino<br /><br />+void *i_private<br /><br />dentry<br /><br />+struct dentry *d_parent<br /><br />+struct qstr d_name<br /><br />+struct inode *d_inode<br /><br />+struct list_head d_child<br /><br />+struct dentry_operations *d_op<br /><br />+struct super_block *d_sb<br /><br />file<br /><br />+struct path f_path<br /><br />+struct inode *f_inode<br /><br />+struct file_operations *f_op<br /><br />+loff_t f_pos<br /><br />+unsigned int f_flags<br />

From the diagram, it can be seen that the super block, as the representative of the file system, contains multiple inodes and dentries. There is an association between inodes and dentries; one dentry points to one inode, while one inode can be pointed to by multiple dentries (hard links). The file object finds the corresponding inode through the dentry, thus enabling access to the file.

Table: Summary of the Four Core Data Structures of VFS

Data Structure	Represents Content	Lifecycle	Disk Correspondence	Main Function
Super Block	File system instance	Created when mounted, destroyed when unmounted	Yes (for disk-based file systems)	Stores file system metadata and management operations
Inode	File or directory metadata	Created when accessing the file, destroyed when no references exist	Yes (for disk-based file systems)	Stores file attributes and data location information
Dentry	Path components	Created during path lookup, destroyed during cache management	No	Constructs directory tree, accelerates path lookup
File Object	Opened file instance	Created when opening a file, destroyed when closing the file	No	Records file session state, provides operation interface

3 VFS Working Principles and Processes

Having understood the core data structures of VFS, we need to further explore how these data structures work together to complete file operation requests. The working principle of VFS can be seen as a series of carefully designed interactive processes, including file opening, reading, writing, and closing operations. These processes fully reflect the value of VFS as an abstraction layer, providing a consistent file access experience for user-space applications through unified interface calls to the specific implementations of different file systems.

3.1 File Opening Process

When a user-space application calls the open() system call to open a file, the Linux kernel triggers a series of complex processing flows, ultimately coordinated by VFS to complete the file opening operation. The detailed steps for opening a file are as follows:

1. System Call Entry: The user-space open() function triggers a soft interrupt, entering the kernel space’s sys_open() function, which is the entry point for system calls.
2. Path Lookup: VFS parses the provided file path, traversing each component of the path. This process involves looking up the directory entry cache; if the required directory entry is not in the cache, VFS calls the directory lookup function of the specific file system to resolve the path step by step.
3. Inode Retrieval: For the last component of the path, VFS retrieves or creates the corresponding inode. If the file does not exist and the O_CREAT flag is specified, VFS calls the file creation method of the specific file system.
4. File Object Allocation: VFS allocates a new file object and initializes its member fields, including setting the file operation table f_op to point to the operation functions provided by the specific file system.
5. File Opening Method Call: If the specific file system implements the open operation, VFS calls this method, allowing the file system to perform specific initialization work.
6. File Descriptor Allocation: VFS allocates a file descriptor for the process, associates the file object with the descriptor, and returns the descriptor to the user-space application.

The following is a sequence diagram illustrating the file opening process using Mermaid, clearly showing the interactions between user space, VFS, and the specific file system:

Disk Cache Specific File System VFS Layer User Space Disk Cache Specific File System VFS Layer User Space alt[Cache Miss]open(path, flags, mode)Path lookup and resolutionLookup directory entry cacheReturn directory entryStepwise lookup directory entryRead directory contentsReturn directory entryCache directory entryRetrieve or create inodeReturn inodeAllocate file objectInitialize file objectCall open method (if exists)Return resultAllocate file descriptorReturn file descriptor

3.2 File Reading Process

File reading is one of the most common operations in a file system. When a user-space application calls the read() system call, VFS coordinates the relevant components to complete data reading. The detailed steps for reading a file are as follows:

1. System Call Entry: The user-space read() function triggers a soft interrupt, entering the kernel space’s sys_read() function.
2. File Descriptor Conversion: VFS looks up the corresponding file object based on the provided file descriptor and checks the file’s open mode and permissions.
3. Locating Read/Write Position: VFS retrieves the current read/write position f_pos from the file object, indicating the starting offset for this read operation.
4. Reading Method Call: VFS calls the read or read_iter function in the file operation table, which are implemented by the specific file system.
5. Data Reading: The specific file system reads data from the storage device based on the data block location information recorded in the inode. To improve performance, Linux uses a page cache mechanism, where data is first read into the memory’s page cache and then copied to the user-space buffer.
6. Updating Read/Write Position: After reading is complete, VFS updates the read/write position f_pos in the file object to reflect the new reading position.
7. Data Return: The read data is returned to the user-space application through VFS.

Performance Optimization Mechanisms: VFS and specific file systems use various techniques to optimize read performance. Read-ahead is an important optimization technique where the system predicts the subsequent data that may be needed based on the current access pattern and pre-loads it into the page cache, thereby reducing the latency of subsequent reads.

3.3 Directory Operations and Path Resolution

Directory operations are another important category of operations in a file system, including creating directories, deleting directories, and reading directory contents. VFS provides a set of unified interfaces for directory operations, while specific file systems are responsible for implementing the specific behaviors of these interfaces.

Path resolution is a key process in VFS that is responsible for converting the file path provided by the user into the corresponding inode. The path resolution process can be summarized in the following steps:

1. Determining the Starting Directory: If the path is an absolute path (starting with /), it begins parsing from the root directory; if it is a relative path, it starts parsing from the current working directory.
2. Stepwise Parsing: VFS splits the path by the separator / into multiple components and then parses each component step by step. For each component, VFS first checks the directory entry cache; if the cache hits, it directly retrieves the corresponding dentry; if it misses, it calls the directory lookup function of the specific file system.
3. Permission Check: During the parsing process, VFS performs permission checks on each directory component in the path to ensure that the current process has search (execute) permissions.
4. Symbolic Link Handling: If a symbolic link is encountered, VFS reads the link content and recursively resolves the path pointed to by the link.
5. Mount Point Handling: If a mount point is encountered, VFS switches to the root directory of the mounted file system to continue parsing.

Path resolution is a relatively time-consuming operation; therefore, VFS uses a directory entry cache to accelerate this process. Frequently accessed path components are cached in memory to avoid repeated disk accesses and parsing operations.

4 Simple File System Implementation Example

To gain a deeper understanding of the working principles of VFS, let us attempt to implement the simplest memory file system. This file system will exist entirely in memory, without relying on any block devices, but will support basic file operations such as creating files and reading/writing files. Through this example, we can intuitively see how the core data structures of VFS are initialized and interact.

4.1 File System Registration and Initialization

First, we need to define and register a file system type. In the Linux kernel, file system types are represented by struct file_system_type:

#include <linux/fs.h><br />#include <linux/module.h><br /><br />#define SIMFS_MAGIC 0x13131313<br /><br />static struct file_system_type simfs_fs_type = {<br />    .owner = THIS_MODULE,<br />    .name = "simfs",<br />    .mount = simfs_mount,<br />    .kill_sb = simfs_kill_sb,<br />};<br /><br />static int __init simfs_init(void)<br />{<br />    int ret = register_filesystem(&simfs_fs_type);<br />    if (ret) {<br />        printk(KERN_ERR "simfs: failed to register filesystem\n");<br />        return ret;<br />    }<br />    printk(KERN_INFO "simfs: filesystem registered successfully\n");<br />    return 0;<br />}<br /><br />static void __init simfs_exit(void)<br />{<br />    unregister_filesystem(&simfs_fs_type);<br />    printk(KERN_INFO "simfs: filesystem unregistered\n");<br />}<br /><br />module_init(simfs_init);<br />module_exit(simfs_exit);

Next, we need to implement the simfs_mount function, which is called when the file system is mounted and is responsible for creating and initializing the super block:

static struct dentry *simfs_mount(struct file_system_type *fs_type,<br />                                  int flags, const char *dev_name, void *data)<br />{<br />    struct dentry *dentry = mount_nodev(fs_type, flags, data, simfs_fill_super);<br />    if (IS_ERR(dentry)) {<br />        printk(KERN_ERR "simfs: failed to mount\n");<br />    } else {<br />        printk(KERN_INFO "simfs: mounted successfully\n");<br />    }<br />    return dentry;<br />}<br /><br />static int simfs_fill_super(struct super_block *sb, void *data, int silent)<br />{<br />    struct inode *root_inode;<br />    <br />    sb->s_magic = SIMFS_MAGIC;<br />    sb->s_op = &simfs_super_ops;<br />    sb->s_maxbytes = MAX_LFS_FILESIZE;<br />    sb->s_blocksize = PAGE_SIZE;<br />    sb->s_blocksize_bits = PAGE_SHIFT;<br />    <br />    // Create root directory's inode<br />    root_inode = simfs_get_inode(sb, NULL, S_IFDIR | 0755, 0);<br />    if (!root_inode) {<br />        return -ENOMEM;<br />    }<br />    <br />    // Create root directory's dentry<br />    sb->s_root = d_make_root(root_inode);<br />    if (!sb->s_root) {<br />        iput(root_inode);<br />        return -ENOMEM;<br />    }<br />    <br />    return 0;<br />}<br /><br />static void simfs_kill_sb(struct super_block *sb)<br />{<br />    printk(KERN_INFO "simfs: superblock destroyed\n");<br />}

4.2 Super Block and Inode Operation Definitions

Next, we need to define super block operations and inode operations. These operation tables contain function pointers for various operations supported by the file system:

static const struct super_operations simfs_super_ops = {<br />    .statfs = simple_statfs,<br />    .drop_inode = generic_delete_inode,<br />    .evict_inode = simfs_evict_inode,<br />};<br /><br />static const struct inode_operations simfs_dir_inode_operations = {<br />    .create = simfs_create,<br />    .lookup = simfs_lookup,<br />    .mkdir = simfs_mkdir,<br />    .rmdir = simfs_rmdir,<br />    .unlink = simfs_unlink,<br />};<br /><br />static const struct file_operations simfs_file_operations = {<br />    .read_iter = generic_file_read_iter,<br />    .write_iter = generic_file_write_iter,<br />    .mmap = generic_file_mmap,<br />    .fsync = noop_fsync,<br />    .llseek = generic_file_llseek,<br />};<br /><br />static const struct inode_operations simfs_file_inode_operations = {<br />    .getattr = simple_getattr,<br />    .setattr = simple_setattr,<br />};

Now, we implement the simfs_get_inode function, which is responsible for creating and initializing an inode:

static struct inode *simfs_get_inode(struct super_block *sb,<br />                                     const struct inode *dir,<br />                                     umode_t mode, dev_t dev)<br />{<br />    struct inode *inode = new_inode(sb);<br />    <br />    if (!inode) {<br />        return NULL;<br />    }<br />    <br />    inode->i_ino = get_next_ino();<br />    inode->i_mode = mode;<br />    inode->i_atime = inode->i_mtime = inode->i_ctime = current_time(inode);<br />    <br />    if (S_ISDIR(mode)) {<br />        inode->i_op = &simfs_dir_inode_operations;<br />        inode->i_fop = &simple_dir_operations;<br />        inc_nlink(inode);  // . directory<br />        inc_nlink(inode);  // .. directory<br />    } else if (S_ISREG(mode)) {<br />        inode->i_op = &simfs_file_inode_operations;<br />        inode->i_fop = &simfs_file_operations;<br />        inode->i_mapping->a_ops = &ram_aops;<br />    }<br />    <br />    return inode;<br />}

4.3 File Creation and Directory Operations

To implement the file creation functionality, we need to define the simfs_create function, which is called when creating a new file:

static int simfs_create(struct inode *dir, struct dentry *dentry,<br />                        umode_t mode, bool excl)<br />{<br />    struct inode *inode;<br />    <br />    inode = simfs_get_inode(dir->i_sb, dir, mode | S_IFREG, 0);<br />    if (!inode) {<br />        return -ENOMEM;<br />    }<br />    <br />    d_instantiate(dentry, inode);<br />    dget(dentry);  // Extra reference to prevent immediate release<br />    <br />    printk(KERN_INFO "simfs: file %s created\n", dentry->d_name.name);<br />    return 0;<br />}

The directory lookup operation simfs_lookup is called during the path resolution process to look up the directory entry with the specified name:

static struct dentry *simfs_lookup(struct inode *dir, struct dentry *dentry,<br />                                   unsigned int flags)<br />{<br />    struct inode *inode = NULL;<br />    <br />    if (dentry->d_name.len == 0) {<br />        return ERR_PTR(-EINVAL);<br />    }<br />    <br />    // In actual implementation, this should look up and return the corresponding inode<br />    // For simplicity, we assume all looked-up files do not exist<br />    // Therefore, return NULL, indicating not found<br />    <br />    return d_splice_alias(inode, dentry);<br />}

4.4 Compilation and Testing

After completing the code implementation, we can compile the file system as a kernel module and test it. Below is the basic content of the Makefile:

obj-m += simfs.o<br /><br />simfs-objs := simfs_main.o<br /><br />KDIR := /lib/modules/$(shell uname -r)/build<br /><br />all:<br />    $(MAKE) -C $(KDIR) M=$(PWD) modules<br /><br />clean:<br />    $(MAKE) -C $(KDIR) M=$(PWD) clean<br /><br />install:<br />    sudo insmod simfs.ko<br /><br />uninstall:<br />    sudo rmmod simfs

After compiling and loading the module, we can mount this file system for testing:

# Compile the module<br />make<br /><br /># Load the module<br />sudo insmod simfs.ko<br /><br /># Create a mount point<br />sudo mkdir /mnt/simfs<br /><br /># Mount the file system<br />sudo mount -t simfs none /mnt/simfs<br /><br /># Test file creation<br />sudo touch /mnt/simfs/testfile<br />sudo echo "Hello VFS" > /mnt/simfs/testfile<br />sudo cat /mnt/simfs/testfile<br /><br /># Unmount the file system<br />sudo umount /mnt/simfs<br /><br /># View kernel logs<br />dmesg | tail -20

Through this simple file system implementation, we can clearly see how VFS interacts with specific file systems: when applications perform file operations, VFS first processes the requests and then calls the corresponding functions implemented by the specific file system. This design allows file system developers to focus on the design of storage strategies and data structures without worrying about integration issues with other kernel subsystems.

5 VFS Debugging and Performance Optimization

In actual production environments, understanding and mastering VFS debugging methods and performance optimization techniques is crucial. Whether for file system developers or system administrators, the ability to diagnose VFS-related issues and optimize file system performance is essential. This section will detail VFS debugging tools, performance optimization methods, and solutions to common problems.

5.1 VFS Debugging Tools and Techniques

Linux provides various tools and mechanisms for debugging VFS and file system-related issues. These tools cover all aspects from kernel-level debugging to user-level monitoring.

Dynamic Debugging and Tracing: The Linux kernel has a powerful debugging infrastructure, especially the dynamic debugging and ftrace framework. For VFS, we can use these tools to trace file system operations:

# Enable dynamic debugging related to VFS<br />echo 'file fs/*.c +p' > /sys/kernel/debug/dynamic_debug/control<br /><br /># Use ftrace to trace file opening operations<br />echo 1 > /sys/kernel/debug/tracing/events/syscalls/sys_enter_open/enable<br />echo 1 > /sys/kernel/debug/tracing/events/syscalls/sys_enter_openat/enable<br />cat /sys/kernel/debug/tracing/trace_pipe

/proc File System: The /proc file system in Linux provides a wealth of data about system status and internal kernel information. The following files are particularly useful for VFS debugging:

# View information about mounted file systems<br />cat /proc/mounts<br /><br /># View file system statistics<br />cat /proc/filesystems<br /><br /># View dentry and inode cache status<br />cat /proc/sys/fs/dentry-state<br />cat /proc/sys/fs/inode-state<br />cat /proc/sys/fs/inode-nr

Debugging VFS Memory Usage: VFS uses various caches (dentry cache, inode cache, page cache) to improve performance, but these caches can also consume a lot of memory. We can monitor cache usage with the following commands:

# View memory and cache usage<br />cat /proc/meminfo<br /><br /># View slab allocator information (including dentry, inode cache)<br />cat /proc/slabinfo | grep -E "dentry|inode_cache"

5.2 VFS Performance Optimization

The performance of VFS and file systems directly affects the overall system’s response speed and processing capacity. Here are some commonly used VFS performance optimization methods:

Adjusting Dirty Page Writeback Parameters: Linux uses page cache to improve file read/write performance, and modified pages (dirty pages) need to be periodically written back to the storage device. By adjusting dirty page writeback parameters, we can find a balance between performance and data safety:

# View current dirty page parameters<br />sysctl -a | grep dirty<br /><br /># Adjust dirty page writeback parameters<br />echo 10 > /proc/sys/vm/dirty_background_ratio<br />echo 20 > /proc/sys/vm/dirty_ratio<br />echo 5000 > /proc/sys/vm/dirty_writeback_centisecs<br />echo 1000 > /proc/sys/vm/dirty_expire_centisecs

Adjusting VFS Cache Pressure: The vfs_cache_pressure parameter controls the kernel's tendency to reclaim memory used for VFS caches (mainly dentry and inode caches):

# View current cache pressure settings<br />cat /proc/sys/vm/vfs_cache_pressure<br /><br /># Increase cache pressure (value > 100), making the kernel more inclined to reclaim VFS caches<br />echo 500 > /proc/sys/vm/vfs_cache_pressure<br /><br /># Decrease cache pressure (value < 100), making the kernel retain more VFS caches<br />echo 50 > /proc/sys/vm/vfs_cache_pressure

Optimizing File System Mount Options: When mounting a file system, different mount options can be selected to optimize performance. For example, for SSD devices, we can use noatime or relatime options to reduce metadata updates:

# Use performance-optimized mount options<br />mount -o noatime,nodiratime,data=writeback /dev/sdb1 /mnt/disk

Table: Commonly Used VFS and File System Performance Optimization Parameters

Parameter	Default Value	Meaning	Optimization Suggestions
`<span>dirty_background_ratio</span>`	10	Threshold for the proportion of dirty pages in system memory, when exceeded, background writeback begins	Increasing this value can reduce writeback frequency but may increase the risk of data loss
`<span>dirty_ratio</span>`	20	Maximum threshold for the proportion of dirty pages in system memory, when exceeded, processes will be blocked for writeback	For write-intensive workloads, this value can be appropriately increased
`<span>vfs_cache_pressure</span>`	100	Controls the kernel’s tendency to reclaim VFS caches	For workloads with many small files, this value can be reduced to retain more caches
`<span>inode-nr</span>`	–	Number of allocated and free inodes in the system	Monitor this value; if free inodes are too few, it may be necessary to adjust the file system
`<span>dentry-state</span>`	–	Status information of the dentry cache	Monitor nr_dentry and nr_unused; if too high, it may indicate the cache is too large

5.3 Actual Debugging Cases

Case 1: File System Mount Not Visible: In some cases, users may encounter issues where the VFS mount is not visible in the system. This is often due to the application not being a native GIO client. Solutions include:

# Check if the gvfs-fuse process is running<br />ps aux | grep gvfs-fuse<br /><br /># If not running, manually start the VFS compatibility mount<br />/usr/libexec/gvfsd-fuse -f /run/user/$(id -u)/gvfs

Case 2: Disk Busy Causing System Unresponsiveness: When the system disk is very busy, it may lead to system unresponsiveness or slow response times. We can diagnose the issue using the following tools:

# Use iotop to view disk I/O usage<br />iotop<br /><br /># Use lsof to see which processes are accessing files<br />lsof +D /path/to/directory<br /><br /># Use ps and kill commands to terminate problematic processes<br />ps aux | grep <process_name><br />kill -9 <process_id>

Case 3: Diagnosing Directory Entry Cache Issues: If the system experiences a decline in path lookup performance, it may be due to inefficient directory entry caching. We can diagnose this as follows:

# View directory entry cache statistics<br />cat /proc/sys/fs/dentry-state<br /><br /># Clear the directory entry cache (for testing)<br />echo 2 > /proc/sys/vm/drop_caches<br /><br /># Then rerun tests and observe performance changes

By combining these debugging tools and optimization techniques, system administrators and developers can effectively diagnose and resolve VFS-related performance issues, ensuring that the file system operates at its best.

6 Summary and Outlook

Through an in-depth analysis of the Linux Virtual File System (VFS), we can clearly see the core value and design essence of VFS as the file system abstraction layer in the Linux kernel. VFS not only implements the Unix philosophy of “everything is a file” but also provides a unified access interface for various heterogeneous file systems, greatly enhancing the flexibility and scalability of the Linux operating system.

6.1 Core Value of VFS

Unified Abstraction and Interface Standardization is the most important value of VFS. By defining core data structures such as super blocks, inodes, dentries, and file objects, along with their corresponding operation tables, VFS establishes a complete file system model. This model allows different file systems to provide a consistent file operation experience to user space while maintaining their unique characteristics. Whether traditional local file systems (like ext4, XFS), network file systems (like NFS, CIFS), or even special pseudo file systems (like procfs, sysfs), they can be seamlessly integrated into the Linux file system hierarchy.

Performance Optimization and Caching Mechanisms are another key contribution of VFS. VFS implements a multi-layer caching system, including dentry cache, inode cache, and page cache. These caches significantly reduce disk I/O operations and improve file access speed. Particularly, the dentry cache, by caching path lookup results, avoids repeated disk accesses and parsing operations, which is crucial for system performance.

Cross-File System Interoperability allows users and applications to transparently access files and directories across different file systems without worrying about the underlying storage details and implementation differences. As mentioned at the beginning of this article, users can easily copy data between vfat and ext3 file systems using the cp command, and this ease of operation is the core value provided by VFS.

6.2 Future Development Trends of VFS

As computing environments continue to evolve, VFS also faces new challenges and opportunities. The following areas may be key directions for VFS’s future development:

Non-Volatile Memory (NVM) and Persistent Memory File Systems: With the proliferation of non-volatile memory technologies like Intel Optane, traditional block device-oriented file system architectures may need adjustments. VFS needs to better support technologies like DAX (Direct Access), allowing applications to directly access persistent memory, bypassing traditional page cache and block I/O layers, thus achieving extremely low access latency.

Cloud-Native and Containerized Environments: In the context of the increasing popularity of containerization and microservices architectures, file systems need to support more flexible mount namespaces, more efficient storage quota management, and more granular access control. VFS may need to enhance support for union file systems like OverlayFS to meet the needs of layered storage for container images and rapid startup.

Enhanced Security: In the face of increasingly severe cybersecurity threats, VFS needs to integrate more robust security features, such as integrity protection, encrypted files and directories, and dynamic permission management. Several subsystems in the kernel are developing new security mechanisms, such as FS-Verity (file integrity) and FScrypt (file system encryption), which will gradually become part of VFS’s standard feature set.

Transparent Access Across Networks: Although VFS already supports network file systems, with the development of edge computing and distributed systems, there are higher demands for performance and transparency in cross-network file access. In the future, VFS may further optimize support for distributed file systems, providing smarter cache consistency mechanisms and fault recovery capabilities.

As a mature and complex kernel subsystem, Linux VFS embodies the wisdom and experience of Linux kernel development in its design philosophy and implementation mechanisms. By deeply understanding VFS, we can not only better manage and optimize Linux systems but also learn how to design scalable, high-performance system software.