bittern.cn
9Linux 内核设计与实现（第3版）

文件系统

VFS

VFSinodedentry超级块

🎯 AI 时代的学习建议：不要只读理论。理解这一章的设计动机（为什么需要这个概念？）和边界条件（什么情况下会失效？）。当 AI 生成的代码涉及这些概念时，你能判断它是否用对了场景。AI 能帮你总结内容，但无法替代你亲手阅读、思考、建立直觉的过程。

第9章 文件系统（Virtual File System）

一、导读

1.1 本章学习目标

理解 VFS（Virtual File System）的设计目标和核心抽象

掌握 VFS 的四个核心对象模型：超级块（superblock）、inode、dentry、文件对象（file）

了解 VFS 如何通过统一的接口支持数十种不同的文件系统

深入理解 dentry 缓存（dcache）的工作原理和路径查找过程

掌握 inode 缓存（icache）的作用和 inode 的生命周期

理解页面缓存（page cache）和缓冲 I/O 的机制

了解 Linux 支持的主要文件系统类型（ext4、XFS、Btrfs、NFS 等）的特点

理解写回（writeback）策略和文件系统一致性保证

1.2 为什么本章如此重要

文件系统是操作系统中最复杂的子系统之一。Linux 支持数十种不同的文件系统——本地的 ext4、XFS、Btrfs，网络的 NFS、CIFS，特殊的 proc、sysfs、tmpfs 等。每种文件系统有自己的磁盘格式、数据组织方式和特性。然而，应用程序通过统一的系统调用（open()、read()、write()、close()）访问所有文件系统，完全不需要关心底层实现。

这种统一性的实现归功于 VFS——虚拟文件系统层。VFS 定义了一套抽象的数据结构和操作接口，各文件系统通过实现这些接口来融入 VFS 框架。VFS 的设计是面向对象思想在 C 语言中的经典应用：通过函数指针表（类似虚函数表）实现多态，不同的文件系统提供不同的函数实现。

VFS 不仅简化了应用程序开发，也极大地简化了文件系统开发。新的文件系统只需实现 VFS 定义的接口，就可以获得路径查找、缓存管理、权限检查等通用功能。理解 VFS 的设计模式，对于开发文件系统驱动、优化 I/O 性能以及理解内核 I/O 路径至关重要。

1.3 核心问题引导

VFS 是如何用一套接口支持数十种不同的文件系统的？其核心抽象是什么？

inode 和 dentry 有什么区别？为什么不直接把文件名存在 inode 中？

路径查找（如 /home/user/file.txt）在 VFS 中是如何完成的？dentry 缓存如何加速这一过程？

页面缓存如何提高文件 I/O 的性能？读缓存和写缓存的策略有什么不同？

什么是"写回"（writeback）？为什么延迟写入可以提高性能？它带来了什么风险？

ext4、XFS、Btrfs 各自的设计特点是什么？它们分别适用于什么场景？

特殊文件系统（如 proc、sysfs）与普通文件系统有什么不同？

文件系统如何保证崩溃后数据的一致性？日志（journal）机制是如何工作的？

二、核心概念详解

9.1 VFS 的四个核心对象

VFS 通过四个核心对象模型来抽象所有文件系统：

超级块对象（superblock）：描述已挂载文件系统的元信息。每个挂载的文件系统有一个超级块对象，包含文件系统类型、块大小、inode 操作函数表、超级块操作函数表等信息。超级块对应磁盘文件系统的超级块（如 ext4 的 superblock），但对于没有磁盘结构的虚拟文件系统（如 proc、pipe），VFS 在内存中创建"伪超级块"。

inode 对象：描述文件系统中一个文件（或目录、设备等）的所有元信息——文件类型、权限、所有者、时间戳、数据块位置等。每个文件有唯一的 inode 编号。inode 不包含文件名，文件名存在于 dentry 中。inode 操作函数表定义了操作该 inode 的方法（如 readpage()、writepage()），由具体文件系统实现。

dentry 对象（目录项）：将路径名的一个分量映射到对应的 inode。例如，路径 /home/user/file.txt 包含四个 dentry：/（根目录）、home、user、file.txt。dentry 是 VFS 中最活跃的对象，路径查找的每一步都需要 dentry。dentry 没有磁盘对应物，完全存在于内存中，通过 dentry 缓存（dcache）管理。

文件对象（file）：描述一个进程打开的一个文件实例。包含文件的读写位置（offset）、打开模式（O_RDONLY、O_WRONLY 等）、关联的 inode 和 dentry、文件操作函数表（read()、write()、llseek() 等）。每次 open() 系统调用创建一个新的文件对象，close() 时销毁。多个进程可以打开同一个文件，各自拥有独立的文件对象。

9.2 路径查找与 dentry 缓存

路径查找是文件系统最频繁的操作之一。当程序调用 open("/home/user/file.txt") 时，VFS 需要将路径名解析为对应的 inode。这个过程从根目录的 dentry 开始，逐级向下查找：

首先查找 / 的 dentry（从当前进程的根目录或文件系统根获取）。然后查找 home：在根目录的 inode 中搜索名为 home 的 dentry。接着查找 user：在 home 目录的 inode 中搜索。最后查找 file.txt。每一步查找都需要读取目录内容（目录本质上是一种特殊文件，内容是 dentry 列表）。

为了加速路径查找，VFS 维护了 dentry 缓存（dcache）。所有最近查找过的 dentry 都缓存在一个哈希表中。下次查找同一路径时，VFS 首先在 dcache 中查找，如果命中则直接返回，无需访问磁盘。dcache 使用 LRU 算法管理，最近使用的 dentry 保留在缓存中。

dentry 缓存还包括别名（alias）管理——一个 inode 可能有多个硬链接（多个 dentry 指向同一个 inode），VFS 通过 inode 的 i_dentry 链表跟踪所有指向该 inode 的 dentry。

9.3 页面缓存与缓冲 I/O

页面缓存（page cache）是 VFS 提高文件 I/O 性能的核心机制。当读取文件时，VFS 首先检查所需数据是否已在页面缓存中。如果在（缓存命中），直接从内存返回数据，无需磁盘 I/O；如果不在（缓存未命中），从磁盘读取数据到页面缓存，然后返回给应用程序。

写入操作采用延迟写入策略（writeback）。应用程序调用 write() 时，数据首先写入页面缓存，标记对应页面为"脏"（dirty）。内核的后台线程（flusher threads）定期将脏页面写回磁盘。这种策略的优势是：合并多次小写入为一次大写入，减少磁盘 I/O 次数；应用程序无需等待磁盘写入完成，提高了响应速度。

延迟写入的风险是：如果系统在数据写回磁盘之前崩溃，未写回的数据将丢失。为了保证数据一致性，应用程序可以调用 fsync() 强制将文件的所有脏页面写回磁盘。文件系统也可以通过日志（journal）机制保证崩溃一致性。

9.4 具体文件系统简介

ext4（Fourth Extended Filesystem）：Linux 最广泛使用的默认文件系统，是 ext3 的继任者。支持最大 1 EB 的文件系统和 16 TB 的文件。使用 extent（连续块范围）代替传统的块指针，提高了大文件的顺序读写性能。支持延迟分配（delayed allocation），在数据实际写回时才分配块，减少碎片。支持日志、在线扩容、快速 fsck 等特性。

XFS：由 SGI 开发的高性能日志文件系统，特别适合大文件和高并发场景。使用 B+ 树管理空间分配，支持并行 I/O 操作。在大规模存储系统（如数据中心）中广泛使用。

Btrfs（B-Tree Filesystem）：现代写时复制（CoW）文件系统。支持快照、透明压缩、数据校验、多设备管理（类似软件 RAID）、在线扩容等高级特性。适合需要数据保护和灵活管理的场景。

三、深入分析与讨论

3.1 文件系统日志与崩溃一致性

文件系统日志（Journal）是保证崩溃一致性的核心机制。以 ext4 为例，日志位于文件系统的固定区域。每次写入操作分为两步：首先将元数据变更写入日志（journal commit），然后更新实际的文件系统数据结构。

日志提交是一个原子操作——通过事务（transaction）机制保证。一个事务包含一组相关的元数据变更。提交时，先将所有变更块写入日志区域，然后写入一个提交记录块。如果提交过程中崩溃，重启时文件系统检查日志：如果有完整的提交记录，则重放（replay）日志中的变更；如果提交不完整，则丢弃该事务。

日志机制保证了元数据的一致性（文件不会在部分更新后变得不可识别），但不保证数据的一致性（文件内容可能不是最新的）。如果需要数据一致性保证，应用程序需要使用 fsync() 或文件系统提供的特殊选项（如 ext4 的 data=journal 模式）。

3.2 VFS 的面向对象设计模式

VFS 是 C 语言实现面向对象设计的经典案例。每个核心对象都包含一个操作函数表（ops table），类似于 C++ 的虚函数表。例如，struct inode_operations 定义了 create()、lookup()、mkdir() 等操作，不同的文件系统提供不同的实现。

c
struct inode_operations {
    struct dentry *(*lookup)(struct inode *, struct dentry *, unsigned int);
    int (*create)(struct inode *, struct dentry *, umode_t, bool);
    int (*mkdir)(struct inode *, struct dentry *, umode_t);
    // ... 更多操作
};

当 VFS 需要执行某个操作时，通过函数指针调用具体文件系统的实现。这种设计使得 VFS 可以在不知道文件系统具体实现的情况下，统一处理路径查找、权限检查、缓存管理等通用逻辑。新的文件系统只需填充操作函数表，即可融入 VFS 框架。

四、实践案例

4.1 案例一：使用 strace 分析文件 I/O 路径

通过 strace -e trace=open,read,write,close statfs ./program 跟踪程序的文件操作。结合 /proc/[pid]/maps 观察共享库的加载过程。使用 cat /proc/mounts 查看系统挂载的文件系统类型。使用 df -T 查看各挂载点的文件系统类型。这些工具帮助理解 VFS 如何在实际系统中工作。

4.2 案例二：分析页面缓存的效果

编写一个程序读取一个大文件，使用 time 命令测量读取时间。然后立即再次读取同一文件（数据已在页面缓存中），对比两次读取的时间差异。通过 cat /proc/meminfo | grep Cached 观察页面缓存的大小变化。使用 echo 3 > /proc/sys/vm/drop_caches 清除缓存后再次测试，验证页面缓存对 I/O 性能的巨大影响。

五、常见误区与注意事项

误区：write() 返回后数据已经写入磁盘。write() 只是将数据写入页面缓存，实际写入磁盘由后台线程异步完成。如果需要保证数据落盘，必须调用 fsync() 或 fdatasync()。

误区：inode 包含文件名。inode 只存储文件的元信息（权限、大小、时间戳、数据块位置），不包含文件名。文件名存储在目录的 dentry 中。硬链接就是多个 dentry 指向同一个 inode。

误区：所有文件系统都存储在磁盘上。虚拟文件系统如 proc、sysfs、tmpfs 不存储在磁盘上，它们的数据完全在内存中生成。proc 导出进程信息，sysfs 导出设备信息，tmpfs 提供基于内存的临时文件存储。

注意：不同文件系统的语义可能不同。例如，某些文件系统支持原子重命名，某些不支持；某些文件系统对文件名大小写敏感，某些不敏感。跨文件系统的操作（如 mv 跨分区）需要复制数据，而非简单的元数据更新。

注意：dentry 缓存占用大量内存。在文件密集的工作负载中，dentry 缓存可能占用数 GB 内存。通过 /proc/sys/vm/vfs_cache_pressure 可以调整内核回收 dentry 和 inode 缓存的倾向。

六、本章小结

本章详细讲解了 Linux 的虚拟文件系统（VFS）设计。VFS 通过超级块、inode、dentry 和文件对象四个核心对象，将数十种不同的文件系统统一在同一套接口下。路径查找从根 dentry 开始逐级解析，dentry 缓存大幅加速了这一过程。页面缓存通过缓存文件数据减少磁盘 I/O，延迟写入策略提高了写入性能但需要日志机制保证崩溃一致性。ext4、XFS、Btrfs 等文件系统各有特点，适用于不同的场景。VFS 的面向对象设计模式是 C 语言实现多态的经典案例，理解这一模式对于开发文件系统驱动和理解内核 I/O 路径至关重要。

七、思考题与练习

画出 VFS 四个核心对象之间的关系图，说明它们如何协作完成一次 open() 操作。

分析 dentry 缓存的哈希冲突处理机制。如果两个不同的路径名哈希到同一个桶，如何处理？

比较 ext4 的 extent 和传统块指针的区别。Extent 如何改善大文件的性能？

编写一个程序，使用 stat() 系统调用获取文件的 inode 信息，验证硬链接的多个文件共享同一个 inode 编号。

研究 Btrfs 的写时复制（CoW）机制。它与传统文件系统的写入方式有什么不同？有什么优缺点？

分析 fsync() 的实现：它如何将页面缓存中的脏页面写回磁盘？它等待什么条件才返回？

比较 tmpfs 和 ramfs 的区别。为什么 tmpfs 有大小限制而 ramfs 没有？

设计一个简单的文件系统需要实现哪些 VFS 接口？列出最小可行的操作函数表。

9/10文件系统
0%