这篇笔记沿着“系统调用 -> VFS层 -> Page Cache -> 块层与I-O调度总览 -> 设备驱动”的顺序理解一次普通文件写入是怎样逐步向下推进的。它适合作为 存储系统总览 中 I/O 写路径的基础入口，也适合和 mmap && write、命令ls的执行过程 对照阅读。

命令write的执行过程

如果把一次 write 看成“把数据写进磁盘”的瞬时动作，那么 Linux 文件 I/O 里最重要的那部分现实就会被整个抹平。对应用来说，write(fd, buf, len) 像是一次写操作；但对内核来说，它首先是一条请求进入文件 I/O 路径的起点。用户态给出的只是一个文件描述符、一段用户缓冲区和一个长度，真正要让这次修改变成系统能够继续管理的状态，还要先经过系统调用边界、VFS 对文件对象的识别、Page Cache 对数据状态的接管、文件系统对修改的组织，以及后续块层和设备路径的实际推进。也就是说，write 的价值不在于它“直接完成了落盘”，而在于它把一次用户态修改正式送进了 Linux 文件 I/O 的整条语义链。

这条链开始于用户态到内核态的切换。应用调用 write 时，最先发生的并不是数据移动到磁盘，而是 CPU 从用户态进入内核态，把文件描述符、用户缓冲区地址、写入长度这些参数交给内核去解释。直到这一步，用户进程都还只是表达了一个意图：我想对某个已经打开的文件写入一段内容。内核接手后，才会继续回答更具体的问题：这个文件描述符对应的是哪个 file 对象，这个 file 对象又属于哪个 inode，这次访问是否允许写，当前偏移在哪里，应该调用哪套具体文件操作。换句话说，write 的第一层真实含义不是“开始写盘”，而是“让内核开始把一个用户态意图整理成可执行的文件语义操作”。

VFS 正是在这里承担第一层组织工作。它不会直接替你把数据写到设备上，但它决定这次请求究竟写向谁、以什么方式写、并交给哪个具体文件系统实现去接住。应用看到的是统一的 write 接口，VFS 看到的则是“某个已经打开的 file 对象收到了一次写请求”。从这个时刻开始，这次修改不再主要由路径名和文件描述符来表示，而开始依附于 inode、file 对象以及对应文件系统的写操作实现。也因此，写路径的第一步并不是磁盘动作，而是对象定位和语义分发。没有这一步，后面的 Page Cache、文件系统回写和块层请求组织都没有可挂接的对象基础。

一旦 VFS 把请求送到了正确的文件对象和文件系统实现上，写路径里最关键的状态变化通常发生在 Page Cache。对很多普通 buffered write 来说，内核并不会把用户缓冲区里的内容同步地一路推到底层设备，而是先把数据拷贝进页缓存，把对应页标记为脏页，并更新文件大小、页状态或相关元数据的内存视图。这里最值得建立的模型是：write 返回成功，最常见地代表“这份修改已经进入当前内核实例所管理的文件状态”，而不是“这份修改已经到达稳定介质”。也正是因为这一步优先发生在内存中，Linux 才能吸收大量小写入、减少同步设备等待，并把原本零散的用户态写请求改造成一个可以延迟、合并和批量推进的后台工作集。

从这里开始，write 路径就天然分成了两个时间层次。前台层次是系统调用本身何时返回，也就是应用什么时候被告知“内核已经接管了这次修改”；后台层次则是这份修改何时真正继续往下推进，也就是脏页何时被文件系统和写回机制送向块层与设备。很多关于 Linux I/O 的误解，恰恰都来自于把这两个层次混成一层。应用往往只观察到 write 返回得很快，于是容易误以为磁盘写入也已经完成；而实际发生的事情通常是，内核只是先接受了修改，并把真正昂贵的落盘工作留给之后的写回、同步或内存压力路径去结算。

如果继续沿着因果链往下看，文件系统在这里接住的已经不再是“用户给了一段字节”，而是“某个文件对象上的哪些页被修改了，这些修改在本文件系统语义里应如何组织”。不同文件系统会有各自的写入路径、元数据更新方式和提交机制，但对这篇基础入口文章来说，最重要的是先抓住共同点：从 Page Cache 继续往下走时，系统开始考虑的不再只是内存中的新内容，而是这些新内容以后要怎样被写回、怎样维护 inode 和目录项一致性、怎样在必要时与日志、事务或延迟分配逻辑发生关系。也就是说，write 并不会绕过文件系统直接变成设备请求；它先成为文件系统内部的一次状态变化，然后才在未来某个时点被继续翻译成更底层的 I/O 意图。

真正靠近设备的位置，是块层接手之后。当前面那些页缓存状态被写回机制推出、并由文件系统翻译成更具体的块访问需求后，系统面对的就不再是“某个文件的内容改了”，而是“某些逻辑块需要被读写、排序、合并和下发”。到这时，请求开始以 bio、request、队列深度和调度策略的形式出现。也就是说，write 路径最后通向设备时，已经和最初的用户缓冲区视角差得很远了。最开始是一个文件语义上的写请求，后面逐渐变成页缓存中的脏页，再继续变成文件系统内部待提交的状态，最后才变成块层和驱动能够理解的设备 I/O 请求。理解 write 路径，最重要的不是死记每一层的函数名，而是建立这种“同一次修改会不断换一种表示方式继续向下走”的模型。

如果只顺着主路径理解，write 看起来像一条线性链：系统调用进入内核，VFS 找到对象，文件系统接管请求，Page Cache 保存新状态，写回把脏页推出，块层组织设备请求，驱动和设备完成最终执行。但工程上真正有价值的，是看到这条链在不同边界上代表的“成功”其实并不一样。对系统调用层来说，成功是参数合法、对象存在、这次写请求已经被内核接受；对页缓存层来说，成功是脏页已经形成、后续可以继续推进；对文件系统来说，成功还牵涉元数据和一致性语义；对块层与设备来说，成功则意味着请求已经真的进入执行路径。把这些边界压扁成一句“write 就是写盘”，就会丢掉 Linux 文件 I/O 最核心的状态分层。

这也是为什么 write 这篇基础文章和后面的 fsync、写回与刷盘语义 必须连起来读。前者主要回答“请求是怎样进入系统并变成内核状态的”，后者继续回答“这些状态何时才算真正越过持久化边界”。没有前面这一层基础，很容易把 fsync 理解成某种额外的落盘技巧；但只要先理解 write 的最常见终点其实是页缓存里的脏页，fsync 的价值就会自然显现出来：它不是把一份本来已经完成的写再做一遍，而是在要求系统尽快结算之前被延迟的那整条后台推进链路。

从学习路径上说，这篇文章最应该帮助建立的，不是某套内核实现细节的完整清单，而是一个足够稳的入口模型：一次普通文件写入，先从用户态意图进入系统调用，再被 VFS 整理成文件对象上的操作，被 Page Cache 接成内存中的新状态，随后才通过文件系统、块层和设备继续向下演化。只要这个模型在脑子里立住，后面无论去看 mmap 与 write 的差异、fsync 的语义、日志与崩溃恢复、块层调度还是多队列路径，都会更容易知道自己是在追这条链的哪一段，而不是在背一堆孤立名词。

进一步讨论

• 【待展开：write 返回成功到底意味着什么｜write-success-semantics】：把系统调用返回成功与真正持久化完成之间的语义边界单独展开。
• 【待展开：脏页从形成到写回的生命周期｜dirty-page-lifecycle】：顺着一次普通写入观察脏页状态如何被内核持续推进。
• 【待展开：buffered write 与 Direct I-O 的路径分叉点｜buffered-write-vs-direct-io-path】：比较普通缓存写与绕过缓存路径从哪个阶段开始明显分叉。