ext4文件系统深度解析：从磁盘布局到Linux VFS文件树与挂载机制

作为一名 Linux 开发者，我们每天都在与文件打交道。然而，对于文件操作背后内核与硬件设备的协作机制，许多人的理解可能仍停留在表面。本文将以应用最广泛的 ext4 文件系统为例，深入剖析 Linux 文件的底层实现原理。

1. ext4 文件系统的磁盘布局

磁盘是海量数据的存储仓库。为了高效利用其存储空间，我们需要将其划分为固定大小的“块”（Block，例如 4KB）。在 Linux 中，块是磁盘 I/O 的基本单位，系统以块为单位进行读写。

当我们获得一块新磁盘时，并不能直接使用。必须经过“分区”和“格式化”两步：分区是在物理磁盘上划分逻辑区域；格式化则是为分区创建文件系统。只有在拥有了文件系统之后，Linux 才能正确识别并访问磁盘。

Linux 支持多种文件系统，如 ext4、XFS、Btrfs 等。其中，ext4 因其稳定性和广泛兼容性，成为最主流的选择。

ext4 文件系统会将一个分区进一步划分为多个“块组”（Block Group）。默认情况下，每个块组的大小为 128MB（包含 32768 个 4KB 块）。一个块组内部的详细结构如下图所示：

图：ext4 文件系统块组结构

块组各部分详解：

• 超级块：存储文件系统的关键元数据，如块大小、inode 总数、文件系统大小等，对应内核中的 struct ext4_super_block 结构体。
• 组描述符表：记录每个块组自身的元数据和使用情况，对应 struct ext4_group_desc。
• 预留 GDT 块：为文件系统未来扩展预留的空间。
• inode 位图：一个位图，标记本块组内哪些 inode 已被使用（1为已用，0为空闲）。
• 数据块位图：一个位图，标记本块组内哪些数据块已被使用。
• inode 表：存储所有 struct ext4_inode 结构体的区域。每个 inode 结构体代表文件系统中的一个文件或目录，包含了除文件名外的所有元数据（权限、大小、时间戳、数据块指针等）。
• 数据块：实际存储文件内容或目录条目（文件名与 inode 号映射）的区域。

目录和文件的内容都存储在数据块中，分别通过 HTree 索引和 Extents 树进行高效管理，限于篇幅，本文不深入展开。

2. Linux 的 VFS 文件树

在用户看来，Linux 的文件系统是一个以根目录 / 为起点的单一树形结构，所有目录和文件都从根目录延伸开来，层次清晰，便于浏览和管理。

图：Linux 用户视角下的文件树

然而，在内核的 VFS 层面，情况则更为复杂。整个文件树是由一个个独立的“挂载实例”组成的。每个挂载实例内部维护着一棵私有的文件树，实例之间通过“挂载点”相互关联，形成更大的逻辑树。

图：Linux 内核视角下的文件树（由挂载实例构成）

理解 VFS 时，我们常聚焦于 dentry（目录项），但这容易让人误以为所有文件都通过 dentry 直接相连。实际上，不同文件系统（挂载实例）内部的 dentry 树是独立的，它们通过挂载点间接关联。

挂载实例的核心数据结构（简化）:

struct mount {
    struct mount *mnt_parent;          // 指向父挂载实例
    struct dentry *mnt_mountpoint;     // 指向挂载点的 dentry
    struct vfsmount mnt;               // 内嵌的 vfsmount 结构
    const char *mnt_devname;           // 设备名，如 /dev/sda1
    // ...
};

struct vfsmount {
    struct dentry *mnt_root;          // 指向本文件系统的根 dentry
    struct super_block *mnt_sb;       // 指向超级块
    // ...
};

• mnt_parent 与 mnt_mountpoint 共同定义了本实例在全局挂载树中的位置。
• mnt_root 是访问本文件系统内部文件的起点。
• mnt_sb 指向具体的文件系统超级块（如 ext4 的超级块）。

私有文件树的构成：dentry
每个挂载实例内部的树形结构由 dentry 构建。其关键字段如下：

struct dentry {
    struct dentry *d_parent;          // 父目录 dentry
    struct qstr d_name;               // 目录项名称
    struct inode *d_inode;            // 关联的 inode
    struct list_head d_child;         // 兄弟节点链表
    struct list_head d_subdirs;       // 子目录链表
    // ...
};

通过 d_parent 和 d_subdirs，内核就能在内存中构建起文件系统的目录树状结构。

为了加速挂载点的查找，内核会根据挂载点路径计算哈希值，将 mount 实例插入全局的 mount_hashtable 中。

3. 挂载 ext4 文件系统的过程

“挂载”的本质，是将一个设备上的文件系统，关联到现有文件树中的一个目录（挂载点）上。

图：ext4 文件系统挂载流程

挂载操作的核心可以概括为：内核创建并初始化一个新的挂载实例，然后将其关联到父挂载实例的指定挂载点上。

当用户执行 mount /dev/sda1 /mnt/data 命令后，内核会：

1. 根据设备名打开块设备，读取 ext4 文件系统的超级块信息。
2. 创建一个 VFS 层的 super_block 对象，并与 ext4 的超级块信息关联。
3. 读取 ext4 文件系统的根目录信息，为其创建 dentry 和 inode。
4. 创建并初始化新的挂载实例：
   • 设置 mnt_sb 指向第2步创建的 super_block。
   • 设置 mnt_root 指向第3步创建的根目录 dentry。
   • 设置 mnt_parent 指向挂载点 /mnt/data 所属的父挂载实例。
   • 设置 mnt_mountpoint 指向挂载点 /mnt/data 的 dentry。
5. 将新挂载实例插入全局挂载哈希表。

至此，ext4 文件系统便成功“嫁接”到了 Linux 文件树上。需要注意的是，ext4 自身的文件树并未与主文件树直接链接。后续访问时，内核需先通过哈希表找到挂载实例，再从其根 dentry 开始访问。

4. 文件路径的解析过程

文件系统挂载成功后，我们便可以通过路径访问其中的文件。文件路径解析是这一切的关键。

图：Linux 打开文件的路径解析过程

当用户程序调用 open(“/mnt/data/docs/test.txt", ...) 时，内核的路径解析过程如下：

1. 内核使用一个 struct path 结构来动态记录当前解析位置（当前 dentry 及其所属的挂载实例）。
2. 从初始路径（绝对路径为根目录/，相对路径为进程当前目录）开始，逐层解析路径分量。
3. 在解析过程中，如果遇到一个目录是“挂载点”，内核会计算哈希值，查找 mount_hashtable，找到对应的子挂载实例。随后，更新 path 结构：将 mnt 指向子挂载实例，dentry 指向子实例的根目录 (mnt_root)。
4. 继续在新的挂载实例内部解析剩余路径分量，直至到达目标文件的父目录。
5. 在父目录中查找或创建目标文件 test.txt 的 dentry 和 inode。
6. 为了进行文件读写，内核会创建一个 struct file 对象，关联到该 inode，并将其与一个未使用的文件描述符绑定，最终将 fd 返回给用户程序。

总结

Linux 秉承“一切皆文件”的设计哲学，其文件系统架构是操作系统的基石之一，涉及存储管理、内存管理和 VFS 等多个子系统的精密协作。本文通过对 ext4 磁盘布局和 Linux VFS 文件树、挂载机制的剖析，希望能帮助你穿透表面，更深入地理解文件操作的底层逻辑。