3. VFS（虚拟文件系统）基础

VFS（Virtual File System，虚拟文件系统）是 Linux 内核中一个至关重要的抽象层。它为上层应用程序（如 open()、read()、write()）提供了一套统一的系统调用接口，而将底层不同物理文件系统（如 ext4、F2FS、FUSE）的具体实现细节隐藏起来。在 Android 系统中，VFS 是连接用户空间与底层存储设备（如 UFS、eMMC）的桥梁，也是文件系统驱动开发者必须掌握的核心知识。

3.1 VFS 概念与架构

VFS 本质上是一个内核软件层，它定义了一组标准的文件系统操作接口（如 struct file_operations、struct inode_operations、struct super_operations）。任何想要被 Linux 支持的文件系统，都必须实现这些接口中的部分或全部函数指针。

下图展示了 VFS 在 Android 系统中的位置及其与各组件的关系：

3.2 四大核心数据结构关系总览

VFS 的核心由四个主要数据结构组成，它们之间的关系可以用“文件路径查找”这一经典场景来串联：

下图清晰地展示了这四个结构体在文件打开过程中的协作关系：

3.3 超级块（super_block）

struct super_block 是 VFS 中最顶层的结构体，它代表一个已经挂载的文件系统实例。每个挂载点（如 /、/data、/system）都对应一个唯一的 super_block 对象。

3.3.1 关键字段

struct super_block {
    struct list_head    s_list;            // 全局超级块链表
    dev_t               s_dev;             // 块设备标识符
    unsigned long       s_blocksize;       // 文件系统块大小 (如 4096)
    loff_t              s_maxbytes;        // 文件最大大小
    struct file_system_type *s_type;       // 文件系统类型 (如 ext4_fs_type)
    struct super_operations *s_op;         // 超级块操作函数表
    struct dentry       *s_root;           // 挂载点的根 dentry
    void                *s_fs_info;        // 指向具体文件系统私有数据 (如 ext4_sb_info)
    // ... 其他字段
};

3.3.2 生命周期

• 创建： 当用户执行 mount 系统调用时，内核通过 s_type->mount() 回调函数创建 super_block 实例。
• 活跃： 在文件系统挂载期间，super_block 始终存在于内存中，管理着该文件系统的所有 inode 和 dentry。
• 销毁： 当执行 umount 系统调用时，内核调用 s_op->kill_sb() 来释放 super_block 及其关联的所有资源。

3.4 inode 结构体

struct inode 是 VFS 中用于描述文件或目录元数据的核心结构体。每个文件或目录在磁盘上都有一个唯一的 inode 编号，在内存中则对应一个 inode 对象。

3.4.1 关键字段

struct inode {
    umode_t             i_mode;            // 文件类型与权限 (S_IFREG, S_IFDIR 等)
    uid_t               i_uid;             // 文件所有者 UID
    gid_t               i_gid;             // 文件所属组 GID
    loff_t              i_size;            // 文件大小 (字节)
    struct timespec64   i_atime;           // 最后访问时间
    struct timespec64   i_mtime;           // 最后修改时间
    struct timespec64   i_ctime;           // 最后状态改变时间
    unsigned long       i_ino;             // inode 编号
    struct super_block  *i_sb;             // 所属超级块
    struct address_space *i_mapping;       // 地址空间 (用于页缓存)
    struct inode_operations *i_op;         // inode 操作函数表
    const struct file_operations *i_fop;   // 默认文件操作函数表
    union {
        struct pipe_inode_info  *i_pipe;   // 管道
        struct block_device     *i_bdev;   // 块设备
        struct cdev             *i_cdev;   // 字符设备
    };
    // ... 其他字段
};

3.4.2 生命周期

3.5 dentry 结构体

struct dentry（目录项）是 VFS 路径查找的核心组件。它不直接对应磁盘上的数据结构，而是内存中用于加速路径解析的缓存实体。每个 dentry 代表路径中的一个分量，例如路径 /data/app/com.example 会分解为根 dentry、data dentry、app dentry 和 com.example dentry。

3.5.1 关键字段

struct dentry {
    struct qstr         d_name;            // 文件名 (快速比较用)
    struct dentry       *d_parent;         // 父目录 dentry
    struct inode        *d_inode;          // 关联的 inode (可为 NULL)
    struct list_head    d_child;           // 父目录的子 dentry 链表
    struct list_head    d_subdirs;         // 子 dentry 链表 (仅目录)
    struct dentry_operations *d_op;        // dentry 操作函数表
    unsigned int        d_flags;           // 标志位 (DCACHE_DISCONNECTED 等)
    // ... 其他字段
};

3.5.2 dentry 状态与缓存

dentry 在内存中有三种状态，理解这些状态对于调试文件系统问题至关重要：

3.6 file 结构体

struct file 代表一个进程打开的文件描述符。它与进程的文件描述符表（fd_array）一一对应，是进程与文件系统交互的直接接口。

3.6.1 关键字段

struct file {
    struct path         f_path;            // 包含 dentry 和 mount 的路径信息
    struct inode        *f_inode;          // 缓存 f_path.dentry->d_inode
    const struct file_operations *f_op;    // 文件操作函数表
    loff_t              f_pos;             // 当前读写位置 (文件偏移量)
    unsigned int        f_flags;           // 打开标志 (O_RDONLY, O_SYNC 等)
    fmode_t             f_mode;            // 打开模式 (FMODE_READ, FMODE_WRITE)
    void                *private_data;     // 私有数据指针 (驱动常用)
    struct address_space *f_mapping;       // 地址空间映射
    // ... 其他字段
};

3.6.2 生命周期

1. 分配与初始化： 当进程调用 open() 系统调用时，内核通过 get_empty_filp() 分配 struct file 实例，然后调用 do_dentry_open() 进行初始化，最终调用 f_op->open() 回调。
2. 使用： 进程通过 read()、write()、ioctl() 等系统调用操作文件，这些调用最终会通过 f_op 中的函数指针分发到具体文件系统的实现。
3. 释放： 当所有进程关闭文件描述符（close()）后，内核调用 fput() 递减引用计数。当引用计数降为 0 时，调用 f_op->release() 回调，然后释放 struct file 内存。

3.7 四者关系总结与生命周期对比

为了更直观地理解这四个结构体的生命周期差异，下表总结了它们的创建与销毁时机：

下图以时间轴的形式展示了这四个结构体在典型场景下的生命周期变化：

3.8 驱动开发中的常见陷阱

• 引用计数管理： 在 open() 回调中，如果增加了一个 inode 或 dentry 的引用计数，务必在 release() 中对应减少。否则会导致结构体无法被回收，造成内存泄漏。
• 并发访问： struct file 的 f_pos 字段在多线程并发读写时可能被竞争。如果驱动需要维护独立的文件位置，建议使用 private_data 存储每个文件描述符的私有上下文。
• dentry 的负缓存： 当查找一个不存在的文件时，VFS 会创建一个负 dentry（d_inode == NULL）。如果后续该文件被创建，需要手动使负 dentry 失效，否则路径查找会一直认为文件不存在。
• super_block 的私有数据： 在 fill_super() 回调中分配的 s_fs_info，必须在 kill_sb() 中释放。这是驱动开发中最常见的内存泄漏来源之一。