Linux 文件 IO 演进史:从 read/write 到 io_uring 的四次范式跃迁

引言：一次 read() 调用背后的 30 年进化

在 Linux 中读取一个文件，最简单的写法不过一行：

ssize_t n = read(fd, buf, 4096);

这行代码在 1991 年 Linux 0.01 内核发布时就能工作，今天依然能工作。但在这 30 多年里，Linux 围绕"文件 IO"这件事，先后引入了 pread、readv、preadv、preadv2、O_DIRECT、libaio、io_uring 等一系列机制。为什么一个已经能用的东西，需要一直演变？

答案不在内核里，而在内核之上——是应用的变化逼迫内核一次次交出控制权。

早期 Unix 的设计者面对的是终端、打印机、管道。文件就是字节流，从头读到尾。内核替你管好一切：偏移量、缓存、调度、阻塞。应用开发者不需要、也不被允许介入这些决策。

但当文件系统之上开始运行数据库引擎、网络服务器、分布式存储系统时，内核的每一个"好意的默认行为"都可能变成性能陷阱。内核替你维护的文件偏移量，在多线程并发读时变成了竞争热点；内核替你管理的 Page Cache，在数据库已有自己的缓存池时变成了内存浪费；内核要求你"一次 IO 一次 syscall"的同步模型，在 NVMe 每秒百万次 IO 的时代变成了吞吐瓶颈。

所以，Linux IO 的演化史，本质上是一部"控制权转移"史：

内核的每一个隐式决策——偏移量管理、缓存策略、IO 调度、执行时机—— 都在某个历史节点上被应用层的需求倒逼为"可选项"。

这篇文章将沿着四次范式跃迁，讲清楚每一次变化背后的应用层痛点、内核的设计权衡、以及解决方案的本质。

第一次跃迁：从"文件是流"到"文件是可寻址的数据结构"

read/write → pread/pwrite

流模型的隐含假设

read/write 是 Unix 文件 IO 的原始接口：

ssize_tread(int fd, void *buf, size_t count); ssize_twrite(int fd, constvoid *buf, size_t count);

这两个接口有一个重要的隐含设计：它们不接受 offset 参数。内核在每个打开的文件描述（struct file）内部维护一个游标 f_pos，read 从 f_pos 处读取，读完后自动推进 f_pos。下一次 read 接着上次的位置继续。

这个设计完美匹配了 Unix 哲学中"文件是字节流"的抽象：cat 从头读到尾，grep 逐行过滤，编译器顺序扫描源代码。流模型简洁优雅，在顺序处理场景下，开发者甚至不需要意识到 f_pos 的存在。

但这个模型有一个隐含假设：同一时刻只有一个执行流在操作这个文件描述符。

数据库引擎暴露了流模型的致命缺陷

想象你在写一个数据库存储引擎。数据存储在一个大文件里，逻辑上被划分为 4KB 的页面（page）。B+ 树的不同层级分布在文件的不同位置。当多个查询并发执行时，多个线程需要同时读取不同位置的页面。

用 read 实现这个需求，你必须这样做：

问题在于：lseek 和 read 是两次独立的系统调用，中间可能被调度打断。如果线程 A 刚执行完 lseek 把 f_pos 设为 1004096，线程 B 紧接着执行 lseek 把 f_pos 改成了 2004096，那线程 A 的 read 实际读到的是页面 #200，而不是 #100。

这是一个经典的 TOCTOU（Time of Check to Time of Use）竞态。f_pos 是 struct file 上的共享可变状态，lseek + read 的两步操作不是原子的。

开发者有两个规避手段，但都代价高昂：

方案一：加锁。对每次 lseek + read 加文件级互斥锁。但在一个每秒执行几万次随机页面读取的数据库引擎中，所有 IO 线程串行化，吞吐量直接崩塌。

方案二：每个线程独立 open。每个线程用自己的 fd，各自有独立的 f_pos。但每个 open 会在内核中创建一个新的 struct file，消耗内核内存和文件描述符资源。当并发线程数达到数百甚至上千时，这个方案同样不可持续。

Linux（遵循 POSIX）引入了 pread/pwrite：

ssize_tpread(int fd, void *buf, size_t count, off_t offset); ssize_tpwrite(int fd, constvoid *buf, size_t count, off_t offset);

表面上看只是多了一个 offset 参数，但这个设计有两个关键决策：

第一，offset 作为参数传入，而非从内部状态读取。这让同一个 fd 上的多次 IO 操作天然可并发——每个调用自带坐标，互不干扰。

第二，pread 不修改 f_pos。这不是实现上的偷懒，而是刻意的设计选择。如果 pread 修改了 f_pos，那它只不过是把 lseek + read 合并成了一个原子操作，f_pos 仍然是共享可变状态。而"不修改 f_pos"意味着 pread 是一个无副作用的操作——给定相同的 fd、offset、count，它的行为完全确定，不依赖也不改变任何外部状态。

这是一种函数式的设计思维：无副作用的操作天然支持并发。

这次跃迁改变了 Linux 对"文件"的基本抽象。

在 read/write 的世界里，文件是一条河流，你只能站在河边，看水从面前淌过。

在 pread/pwrite 的世界里，文件是一本书，你可以翻到任意一页直接阅读。

更深层地说，这是 IO 操作的第一次"去状态化"——把隐藏在内核中的共享可变状态（f_pos），变成了由调用方显式传入的值。这个模式会在后续的演化中反复出现：内核的隐式控制，逐步让位于应用的显式表达。

readv/writev → preadv/pwritev → preadv2

即便有了 pread，每次读写操作仍然是：一次系统调用，搬运一块连续的内存。

这在两类场景下成为瓶颈：

场景一：协议解析。一个 HTTP 响应由 header 和 body 组成，它们在内存中通常不连续（header 是栈上或堆上的小缓冲区，body 可能是mmap 的文件区域）。要把它们写入一个 TCP socket 或一个日志文件，开发者面临选择：

方案 A 的问题是两次 syscall 的开销（每次约 1μs 的用户态-内核态切换），且两次 write 之间不是原子的——在多线程写同一个日志文件时，两个线程的 header 和 body 可能交错。

方案 B 的问题是多了一次 memcpy 和一次内存分配。

场景二：数据库批量刷盘。存储引擎将多个脏页写回磁盘时，这些页面在内存中的地址不连续。如果逐页调用 pwrite，每秒数万次 syscall 的开销在高频场景下显著可测。

Linux 引入了向量化 IO（vectored IO）：

一次系统调用，搬运多块不连续的内存。这个设计借鉴了硬件领域的 scatter/gather DMA 概念——DMA 控制器可以把多个不连续的物理内存块一次性搬到设备，不需要软件先把它们拼成一整块。

writev 的原子性保证尤其重要：内核保证一次 writev 写入的所有 iov 在文件中是连续的，不会被其他线程的写入打断。这意味着多线程写日志时，不需要加锁也能保证每条日志的完整性。

既然 pread 解决了"无状态随机访问"，readv 解决了"批量搬运"，自然的下一步是把两者组合起来：

ssize_tpreadv(int fd, conststruct iovec *iov, int iovcnt, off_t offset);

preadv 同时具备了 pread 的无状态语义和 readv 的向量化能力。对于数据库引擎来说，这意味着可以在一次 syscall 中，从文件的指定偏移处读取数据并散布到多个不连续的内存区域——比如同时填充 B+ 树节点的header结构体和data payload。

到这一步，IO 操作从一个简单的"读/写"动词，开始变成了一个可组合的原语（primitive）：由 offset（位置）、iov（数据布局）、fd（目标）三个正交的参数定义。

2016 年 Linux 4.6 引入 preadv2/pwritev2，多了一个 flags 参数：

ssize_tpreadv2(int fd, conststruct iovec *iov, int iovcnt,                 off_t offset, int flags);

这个 flags 参数让 IO 操作从"描述数据搬运"升级为"表达调度意图"：

RWF_NOWAIT —— "如果数据不在 Page Cache 里，不要阻塞我，立即返回 EAGAIN"。这个 flag 的价值在于协程运行时（coroutine runtime）：当用户态调度器管理着数千个协程时，一个协程发起 IO 不应该阻塞整个线程。有了 RWF_NOWAIT，调度器可以先试探性地读一下，如果 cache miss 就挂起当前协程、切换到其他协程继续执行，稍后再重试或走异步 IO 路径。

RWF_HIPRI —— "这个 IO 很紧急，请用 polling 模式处理"。

传统 IO 通过中断通知完成，中断的延迟在几微秒级别。但在 NVMe SSD 上，IO 本身可能只需要 10-20 微秒，中断延迟反而占了相当比例。RWF_HIPRI 告诉内核使用轮询（polling）方式等待 IO 完成，以牺牲 CPU 时间换取更低的延迟。这对实时数据库查询这类延迟敏感场景至关重要。

RWF_DSYNC —— "只对这一次写入做同步刷盘，不影响其他写入"。传统的 O_DSYNC 是 open flag，粒度是整个文件描述符。RWF_DSYNC 把持久性控制细化到了单次 IO 级别——比如数据库可以对 WAL（预写日志）的写入加 RWF_DSYNC 保证持久性，而对临时数据的写入不加，避免不必要的刷盘开销。

这次跃迁的本质是 IO 接口的表达力不断增强。从 read 只能说"读这么多字节"，到 preadv2 可以说"从这个位置，按这种内存布局，以这种调度策略，读这些数据"。

IO API 从一个"数据搬运指令"进化为一个"调度意图表达协议"。应用不再只是告诉内核"搬什么"，还能告诉内核"怎么搬"以及"以什么优先级搬"。

Buffered IO → Direct IO（O_DIRECT）

Linux 默认的 IO 路径是 Buffered IO。当你调用 read 时，数据的实际流向是：

磁盘 → Page Cache（内核内存）→ copy_to_user → 用户缓冲区

当你调用 write 时：

用户缓冲区 → copy_to_user → Page Cache → （稍后）writeback 到磁盘

Page Cache 是内核在用户和磁盘之间插入的一层透明缓存。它带来了几个好处：

第一，热数据加速。频繁访问的文件内容驻留在内存中，后续读取直接命中 cache，不需要访问磁盘。对于反复读取配置文件、共享库的场景，这几乎是零成本的巨大加速。

第二，写入合并。多次小写入先在 Page Cache 中合并，由内核的 writeback 机制批量刷盘，减少磁盘 IO 次数。

第三，预读（readahead）。内核检测到顺序读取模式时，会提前把后续的数据块加载到 cache 中，让应用感觉磁盘速度更快。

对于 shell 脚本、命令行工具、Web 服务器的静态文件服务这类场景，Page Cache 是一个"开箱即用、不需要任何配置"的性能加速器。

但如果你正在开发 MySQL InnoDB 或 RocksDB，Page Cache 会从好意变成负担。原因有三：

第一，双重缓存浪费内存。InnoDB 有自己的 Buffer Pool，RocksDB 有自己的 Block Cache。这些应用层缓存的设计是为了精确控制哪些数据驻留在内存中。但 Buffered IO 意味着同一份数据会在应用层缓存和 Page Cache 中各存一份。如果你给 InnoDB Buffer Pool 分配了 64GB 内存，Page Cache 又缓存了同样的 64GB 数据，你实际上浪费了 64GB 内存。

第二，缓存淘汰策略冲突。内核的 Page Cache 使用一种近似 LRU 的淘汰算法，它不理解应用的访问模式。一个经典的灾难场景：DBA 执行了一次全表扫描（备份或分析查询），大量冷数据涌入 Page Cache，把数据库的热数据页挤出去。全表扫描结束后，正常的 OLTP 查询突然变慢，因为热数据需要重新从磁盘加载。数据库自己的 Buffer Pool 有专门的淘汰策略来避免这种问题（比如 InnoDB 的"young/old list"机制），但 Page Cache 的行为完全不受应用控制。

第三，持久性控制困难。数据库的正确性依赖于 WAL（Write-Ahead Log）协议：日志必须在数据之前持久化到磁盘。但 Buffered IO 的 write 只是把数据写入 Page Cache，实际刷盘的时机由内核决定。应用必须显式调用 fsync 来强制刷盘，但 fsync 会刷出该文件的所有脏页，粒度太粗。更糟糕的是，在 writeback 期间发生断电，Page Cache 中的脏数据可能丢失，而应用以为 write 已经成功了。

面对这些问题，Linux 提供了 O_DIRECT 选项：

int fd = open("/data/db.ibd", O_RDWR | O_DIRECT);

使用 O_DIRECT 打开的文件，read/write 会绕过 Page Cache，数据直接在用户缓冲区和磁盘设备之间通过 DMA 传输：

磁盘 → DMA → 用户缓冲区    （读取）
用户缓冲区 → DMA → 磁盘    （写入）

这个设计背后有几个值得深究的权衡：

为什么是 open flag 而不是 read/write 的参数？因为在早期设计中，数据路径的选择被视为"文件级策略"——你要么打算缓存这个文件，要么不打算。这是一个在打开文件时就确定的决策，不是每次 IO 时临时切换的选项。（后来 preadv2 的 RWF_DSYNC 打破了这个假设，开始支持每次 IO 粒度的路径控制。）

为什么 O_DIRECT 有对齐要求？使用 O_DIRECT 时，用户缓冲区的地址、IO 的大小、文件偏移量通常需要按 512 字节或 4KB 对齐。这不是内核故意为难开发者。绕过 Page Cache 后，DMA 控制器直接访问用户态内存，而 DMA 硬件要求内存地址和传输长度满足对齐约束。Page Cache 的存在正是屏蔽了这些硬件细节——内核的 Page Cache 页面天然是对齐的，copy_to_user 可以搬运任意大小的数据。选择 O_DIRECT，本质上是选择自己承担原本由内核 Page Cache 代为处理的硬件约束。

为什么不直接废弃 Page Cache？因为绝大多数应用——脚本、命令行工具、编辑器、配置文件读取——受益于 Page Cache 且无需感知它的存在。O_DIRECT 是给那些"比内核更了解自己访问模式"的应用准备的逃逸舱口（escape hatch），而不是默认路径的替代品。

这次跃迁的核心不是"绕过缓存"，而是"缓存管理权的转移"。

在 Buffered IO 的世界里，内核是一个全权代理：它替你决定缓存什么、淘汰什么、什么时候刷盘。应用对数据路径没有任何控制权。

O_DIRECT 把这个决策权交还给了应用。数据库引擎可以用自己精心设计的缓存策略替代内核的通用 LRU，用自己的刷盘时机保证事务的持久性语义。

这个模式与第一次跃迁完全一致：内核的"隐式替你管理"变成了"显式由你选择"。只不过第一次交出的是偏移量管理权，这次交出的是缓存管理权。

同步 IO → Linux AIO → io_uring

前三次跃迁解决了 IO 的语义（怎么描述 IO）和数据路径（数据怎么走）问题。但它们都没有触及一个更底层的问题：执行模型。

无论是 read、pread 还是 preadv2，应用线程的执行流程都是：

调用 syscall → 陷入内核 → 等待 IO 完成 → 返回用户态

线程在 IO 期间被阻塞。这在机械硬盘时代问题不大——一次磁盘寻道需要数毫秒，阻塞一下无所谓。但 NVMe SSD 改变了一切。

一块现代 NVMe SSD 的随机读延迟约 10-20 微秒，IOPS（每秒 IO 次数）可以达到数十万甚至上百万。而一次系统调用的开销——用户态到内核态的上下文切换、参数校验、调度——大约在 1 微秒级别。

算一笔账：如果单线程每秒要完成 100 万次 IO，每次 IO 至少需要 1 次 syscall，每次 syscall 开销 1μs，那光是 syscall 开销就需要 1 秒。也就是说，即使磁盘可以每秒做 100 万次 IO，单线程被 syscall 开销限制在了 100 万次/秒的天花板上——而这还没算 IO 本身的等待时间。

更现实的场景是：应用需要开大量线程来并发发起 IO，而每个阻塞线程的栈内存（通常 8MB）和调度开销又成了新的资源瓶颈。

磁盘不再是瓶颈，syscall 才是。 

Linux AIO（libaio）：一次不成功的尝试

Linux AIO（通过 libaio 库暴露的io_submit/ io_getevents 接口）是第一次尝试解决这个问题：

设计思路是正确的：把 IO 的提交和完成分离，应用提交请求后不阻塞，可以继续做其他事情，稍后再来收割完成事件。

但 Linux AIO 的实现有严重的局限性：

只支持 O_DIRECT。如果你用 Buffered IO，io_submit 会退化为同步行为，失去异步的意义。这意味着只有已经使用 O_DIRECT 的数据库引擎才能受益。

io_submit 在某些情况下仍会阻塞。比如元数据操作需要获取锁时，io_submit 可能阻塞在内核中，破坏了"异步"的承诺。

只支持读写操作。fsync、fstat、openat 等操作都不支持异步。对于需要在 IO 流水线中穿插 fsync 的数据库来说，这意味着异步路径中仍然存在同步的"路障"。

API 不是标准接口。这套接口不属于 POSIX，也不属于 glibc。而 POSIX 标准定义的 aio_read / aio_write（glibc 实现）更是用用户态线程池模拟异步，性能甚至不如直接用同步 IO + 自己的线程池。

结果是：Linux AIO 沦为一个小众接口，只有少数数据库（如 MySQL InnoDB 的特定配置）在使用。大部分需要高性能 IO 的应用选择了另一条路。

面对 AIO 的不成熟，工业界走出了一条务实的路：用 epoll 做事件通知 + 用线程池做同步 IO。

Nginx、Node.js（libuv）、以及大量网络服务框架都是这种模式。对于网络 IO 来说它工作得不错，因为 epoll 天然支持 socket 的可读/可写事件。

但对于文件 IO，这个方案有本质缺陷：epoll 不能有效地监控文件 IO 的完成事件（磁盘文件总是"可读"的，epoll_wait 会立即返回，没有实际意义）。所以文件 IO 只能退化为"线程池中的同步 IO"——它不是真异步，只是把阻塞藏在了 worker 线程里。线程池的大小难以调优：太小则 IO 并发度不够，太大则线程上下文切换开销抵消了并发收益。

2019 年 Linux 5.1 引入的 io_uring（作者 Jens Axboe）从根本上重新设计了 IO 的执行模型。它的核心创新是：用共享内存替代 syscall 作为用户态和内核态的通信通道。

io_uring 在用户态和内核态之间建立了两个环形缓冲区（ring buffer）：

SQ（Submission Queue，提交队列）：用户态写入，内核态读取CQ（Completion Queue，完成队列）：内核态写入，用户态读取

提交一个 IO 请求的过程变成了：

在 SQPOLL 模式下，甚至第 3 步的 syscall 都可以省掉——内核启动一个专门的轮询线程持续检查 SQ，用户态完全不需要任何 syscall 就能完成 IO。

这意味着：批量提交 100 个 IO 请求，可能只需要 0-1 次 syscall，而传统模式需要 100 次。

io_uring 解决了前面所有方案的痛点：

io_uring 还引入了两个减少开销的机制：

Fixed Buffers（注册缓冲区）。传统 syscall 每次都要把用户 buffer 的地址映射到内核的页表中。io_uring 允许预先注册一组 buffer，后续 IO 直接引用注册编号，避免重复的映射操作。

Fixed Files（注册文件描述符）。同理，预先注册一组 fd，后续 IO 直接用编号引用，避免每次 IO 的 fd 查找开销。

这次跃迁改变的是用户态和内核态的交互模型。

传统 IO 是"请求-响应"模型：应用每次 IO 都要"敲门"（syscall）→ 内核开门处理 → 返回结果。交互的单位是一次 syscall。

io_uring 是"生产者-消费者"模型：应用和内核共享一个消息队列，应用持续生产 IO 请求，内核持续消费并产出结果。交互的单位不再是单次 IO，而是一整批。

用一个类比：传统 IO 像是在柜台排队——每个顾客走到窗口、提交请求、等待处理、拿到结果、离开。io_uring 像是一个无人传送带——顾客把请求放上传送带就可以走了，处理好的结果从另一条传送带出来。没有排队，没有等待，没有柜台交互。

内核的角色也发生了根本变化：从"被动响应 syscall 的服务员"变成了"持续运转的 IO 处理引擎"。

全景回顾：一张表、一条线

把四次跃迁放在一起，可以看到一个统一的演进脉络：

这张表的最右列揭示了贯穿全文的统一逻辑——Linux IO 的演化，就是内核将以下决策权逐步移交给应用层的过程：

每一次交权都遵循相同的模式：某类应用发展到一定规模后，内核的通用默认行为不再适用，于是内核开放一个新的控制接口，让"比内核更了解自身需求"的应用可以自行决策。

尾声：演化还在继续

io_uring 看似已经是"终极形态"，但演化从未停止。

io_uring 的安全争议：io_uring 显著扩大了内核的攻击面。共享内存环形缓冲区、内核轮询线程、固定缓冲区映射——这些机制为内核引入了大量复杂的状态管理代码，也带来了潜在的安全漏洞。Google 的 ChromeOS 和 Android 一度禁用了 io_uring。安全性和性能之间的张力，是每一次控制权转移都要面对的永恒问题。

用户态存储栈的兴起：SPDK（Storage Performance Development Kit）代表了一个更激进的方向——连内核都绕过去。SPDK 通过 UIO/VFIO 将 NVMe 设备直接映射到用户态，由用户态驱动程序直接操作硬件寄存器，完全消除了 syscall 和内核协议栈的开销。这与网络领域的 DPDK（Data Plane Development Kit）异曲同工。

如果 Linux IO 的演化逻辑是"不断将控制权从内核移交给应用"，那么 SPDK 就是这条线的逻辑终点——应用直接与硬件对话，内核退出了数据路径。当然，这也意味着应用必须自己处理安全隔离、资源共享、错误恢复等一切内核原本代劳的事情，并非所有场景都值得付出这个代价。

回顾全局，Linux 文件 IO 的 30 年进化可以浓缩为一句话：

文件 IO 的每一次进化，都是应用对内核说"这件事我自己来"—— 从偏移量管理，到缓存策略，到调度控制，到执行模型。 这是一部从"被内核代管"到"自主决策"的应用解放史。