VFS层

如果把 Linux 文件 I/O 看成一条连续路径，那么 VFS 的价值并不在于“再多介绍一种文件系统抽象名词”，而在于它决定了用户态发出的文件操作，是如何从“面向路径名和文件描述符的请求”，变成“面向具体 inode、页缓存与文件系统实现的内核工作”。应用程序调用 open、read、write 时，并不会直接碰到 ext4、XFS 或 btrfs 的私有实现；内核先让这些请求进入 VFS 这一层，由它把统一接口、路径解析、权限检查、对象生命周期和具体文件系统操作衔接起来。也正因为如此，VFS 不是 I/O 路径边上的一个辅助件，而是“通用文件语义”真正落地的第一层组织者。

从路径的角度看，VFS 首先解决的是“同一种系统调用，为什么可以落到不同文件系统上”这个问题。用户态看到的 open("/data/a.txt")、read(fd, ...)、write(fd, ...) 这些接口，在语义上都只是文件操作，但对内核而言，背后可能对应本地磁盘文件系统、网络文件系统、伪文件系统，甚至设备文件。VFS 提供的不是某个具体存储结构，而是一组稳定的内核对象和操作约定，使上层系统调用能够先面向统一抽象编程，再由底层具体文件系统把这些抽象接住。这样一来，系统调用层不需要为 ext4、XFS、tmpfs、procfs 分别维护一套完全不同的入口，文件系统实现也不需要重新发明一整套用户接口。

这层统一抽象最关键的，不是“支持很多文件系统”这句结论本身，而是它通过若干核心对象，把文件操作拆成了可以持续传递状态的中间形态。路径名首先会被解析到目录项，再定位到 inode，随后在成功打开后形成 file 对象，由 file 对象承载后续读写偏移、访问模式和操作方法。换句话说，VFS 做的第一件大事，是把“字符串形式的路径”和“短暂发起的系统调用”，转化成一组可以在内核里持续存在、反复引用、继续向后传递的结构化状态。只有经过这一步，后面的 Page Cache、文件系统写入路径、块层请求组织才有了可以依附的对象基础。

对读路径来说，VFS 的价值最直观地体现在路径解析与对象定位上。像 ls 这样的命令，本质上不是先去磁盘上“扫一遍文件”，而是先由 VFS 把路径逐级解析出来：当前进程的工作目录是什么，要访问的挂载点在哪里，路径中的每一级名字对应哪个目录项，最终又落到哪个 inode 上。于是 ls 真正依赖的第一批关键动作，并不是块设备 I/O，而是目录项查找、缓存命中、权限校验和 inode 定位。也就是说，在很多读路径里，VFS 先决定“你到底在读谁”，后面的文件系统和缓存层才继续决定“这个对象的数据现在在哪里、要不要去介质上取”。如果这个顺序没有建立起来，读路径就会被误看成一个过早落到底层设备的问题。

写路径里，VFS 的角色同样不是直接负责“把数据写下去”，而是把一次写请求送到正确的语义边界上。应用调用 write(fd, buf, len) 之后，VFS 首先依据 file 对象确认这是什么文件、当前偏移在哪里、这次访问是否允许写、应调用哪套文件操作，然后再把控制权交给对应文件系统实现。到了这一步，数据是否进入 Page Cache、何时变成脏页、何时组织成 bio、何时被块层调度，都已经是 VFS 之后的问题。于是可以把 VFS 理解成这样一个边界层：它不决定最终落盘节奏，却决定这次 I/O 请求以什么对象身份、什么访问语义、什么调用约束进入后续路径。

从结构职责上说，VFS 主要承接了四类问题。第一类是命名空间问题，也就是路径、挂载点、目录层级和文件名该怎样映射到具体对象。第二类是统一操作接口问题，也就是 open/read/write/fsync/mmap 这类通用操作如何以一致方式进入不同文件系统。第三类是权限与状态问题，也就是访问模式、打开标志、偏移更新、引用计数、对象生命周期如何被内核持续维护。第四类才是向下转发问题，也就是当对象已经被正确识别后，具体应由哪个文件系统实现去接手后续动作。把这四类职责放在一起看，VFS 真正解决的是“文件 I/O 在进入具体存储机制之前，怎样先被整理成内核可处理的通用语义对象”。

但也正因为 VFS 处在这个位置，最容易出现的误解就是把它想成“文件系统总控中心”，仿佛后面所有事情都由它统一完成。实际上，VFS 的统一主要体现在接口与对象层，而不是体现在所有细节机制都被它接管。它不直接等同于 Page Cache，也不等同于块层，更不负责替不同文件系统消除实现差异。缓存命中与否、脏页如何管理、日志怎样提交、请求怎样下沉到设备，这些问题都发生在它之后。VFS 做的是把通用文件语义整理好，再把请求交给正确的下游。理解这一点很重要，因为这能帮助我们把“语义入口”和“数据推进路径”分开看：VFS 负责把门，Page Cache 负责承接运行时数据状态，块层负责把已经形成的 I/O 需求继续组织到设备前。

这也是为什么 VFS 很适合被放在 I-O语义与路径 这条主线最前面。它不是单纯的入门背景知识，而是后面几篇文章的共同前提。没有 VFS，就很难准确理解 Page Cache 为什么是“以文件对象和页为单位”管理状态；也很难理解 write 为什么先表现成文件语义上的修改，再逐步演化成回写与块层请求；更难理解同样的系统调用接口，为何能统一地跨越本地文件、网络文件和伪文件系统。换句话说，VFS 的位置不在“设备之前的某个小细节”，而在“通用文件 I/O 正式开始成立”的那个入口点。

如果把这篇文章压缩成一个最值得反复复用的模型，那么我会把 VFS 看成“Linux 文件 I/O 的语义整理层”。它接住的是路径名、文件描述符和系统调用，向后交出去的是 inode、file 对象和具体文件系统操作；它先回答“这次访问的是谁、是否允许、该用哪套实现”，然后才让后续层次继续回答“数据当前在哪、要不要进缓存、何时下推到设备”。抓住这个模型之后，前面的 ls 路径解析、后面的 Page Cache、再往后的写回与块层，都会变得更容易挂到同一条理解链上。

进一步讨论

• 【待展开：dentry、inode、file、super_block 的职责边界｜vfs-object-boundaries】：把 VFS 四个核心对象的职责边界与状态传递关系拆开讲清楚。
• 【待展开：open/read/write 在 VFS 中如何分发到 file_operations｜vfs-file-operations-dispatch】：把系统调用进入 VFS 之后的分发路径落实到具体操作表。