1.1 磁盘与 CPU 速度鸿沟
Linux 块设备缓存机制的本质目标，是缓解 CPU 与存储设备之间巨大的速度差异。现代 CPU 纳秒级执行，而机械硬盘随机访问可能需要毫秒级，即使 NVMe SSD 延迟也远高于内存访问。如果每次 read/write 都直接访问磁盘，CPU 大量时间都会浪费在 I/O 等待上。
Linux 并不会让用户进程直接操作块设备，而是在内存中建立缓存层。应用读文件时，数据优先从内存返回；写文件时，数据先进入缓存，稍后再异步刷盘。这样磁盘 I/O 被“批量化”和“异步化”，系统整体吞吐量会显著提升。
1.2 Linux 缓存架构演化
早期 Linux 同时存在：Buffer Cache和Page Cache
Buffer Cache 面向块设备，Page Cache 面向文件页，两套缓存长期并存导致数据重复缓存。例如同一个文件页可能既存在 page cache，又存在 buffer cache。
Linux 2.4 之后逐渐完成统一缓存架构：
Page Cache 成为核心Buffer Head 仅描述块映射
现代 Linux 中文件系统缓存基本都建立在 page cache 之上，而 buffer cache 更多用于 metadata 与块映射管理。理解这一演化非常关键，否则很多开发者会误以为 Linux 仍然存在独立 buffer cache 数据缓存体系。
第二章 Page Cache 核心机制
2.1 Page Cache 本质结构
Linux Page Cache 的核心对象是：struct address_space，每个 inode 都关联一个 address_space：inode->i_mapping其内部维护 page cache 树，用于管理文件页，用户 read 文件时：
read() ↓page cache 查找 ↓命中则直接返回 ↓未命中则触发磁盘读取
因此 Page Cache 本质上是：文件页缓存系统，它并不关心具体文件系统，而是 Linux VFS 层统一缓存框架。
2.2 文件读取流程
典型文件读取流程：
用户 read ↓VFS ↓page cache lookup
如果 page 已存在：直接 copy_to_user，否则：
分配 page ↓提交 block I/O ↓等待磁盘完成 ↓填充 page cache
随后 future read 都会命中缓存。
Linux 之所以使用 page 作为缓存单位，是因为 MMU 本身以 page 为内存管理粒度。统一 page 粒度后，文件缓存与虚拟内存能够共享同一套页管理体系。
第三章 写缓存与脏页机制
3.1 Linux 为什么延迟写回
Linux 写文件时通常不会立即刷盘：write(fd, buf, size);write 返回时，数据大概率仍停留在 page cache。内核只是将 page 标记为：dirty page，随后后台线程异步刷盘，原因很简单：磁盘随机写极其昂贵。如果每次 write 都立即触发设备 I/O，系统性能会急剧下降。因此 Linux 使用 delayed write，将大量小写操作合并成顺序大块写入。
3.2 Dirty Page 回写机制
Linux 内核存在专门回写线程：
flush threadwriteback worker
它们周期性扫描 dirty page：
dirty_expire_centisecsdirty_ratiodirty_background_ratio
达到阈值后启动 writeback，完整流程：
write ↓page cache ↓mark dirty ↓后台 writeback ↓bio 提交 ↓块设备
所以 Linux 文件写入真正核心思想是：
这也是为什么突然断电可能导致数据丢失，因为 dirty page 可能尚未真正落盘。
第四章 Buffer Head 与块映射机制
4.1 buffer_head 的作用
虽然现代 Linux 以 page cache 为核心，但 buffer_head 仍然存在：struct buffer_head作用不再是缓存数据，而是描述：page 中哪些 block 对应磁盘哪些 sector，因为文件系统最终仍然运行在 block device 之上。page 是内存管理单位，而 block 是文件系统最小存储单位，两者大小可能不同，例如：
则一个 page 可能对应多个 buffer_head。
4.2 文件系统块映射流程
ext4 读取文件：
逻辑文件偏移 ↓inode block mapping ↓物理 sector
buffer_head 就负责保存：
sector numberbuffer stateuptodatedirty等信息。
现代 Linux 中很多高性能文件系统已经逐渐绕过 buffer_head，例如：
因为 buffer_head 粒度较小，在 NVMe 高并发场景下会带来额外开销。
第五章 Block Layer 与 bio 机制
5.1 bio 为什么出现
Linux 块层早期使用：buffer_head directly submit但这种模式难以支持大 I/O 合并，因此后期引入：struct bio，bio 本质上描述：一次块 I/O 请求，其内部包含多个 page vector，例如：
多个 page ↓合并为 bio ↓统一提交 block layer
这样可以减少设备请求次数，提高磁盘吞吐能力。
5.2 bio 提交流程
Page Cache 回写后：
dirty page ↓bio_alloc ↓submit_bio ↓request queue
块层随后继续执行：
I/O mergeelevator schedulingdispatch
最终驱动生成 DMA 请求访问设备，因此 Linux block I/O 真正的数据路径：
page cache ↓bio ↓request ↓driver ↓hardware
现代 Linux 大部分块层优化，本质都围绕 bio merge 与 queue 调度展开。
第六章 块设备缓存优化机制
6.1 Read Ahead 预读机制
Linux 文件顺序读取时，会自动触发 readahead：
用户读取：page 0 内核可能提前加载：page 1~31这样下次 read 能直接命中 page cache，Readahead 本质上属于：空间换时间，因为磁盘顺序读取远快于随机读取。尤其机械硬盘场景下，readahead 能显著减少 seek 开销。
6.2 Writeback 合并优化
Linux 写缓存另一个关键优化是 I/O merge。多个 dirty page 回写时：
连续 sector ↓合并 bio ↓减少 request 数量
NVMe SSD 虽然随机访问性能远高于 HDD，但 Linux 仍然会进行 merge，因为 PCIe transaction 与 DMA setup 仍然存在固定成本。
现代 Linux block layer 已经逐渐从减少 seek转向：
减少 CPU 开销减少 queue lock提高并行度
这也是 blk-mq 出现的重要背景。
第七章 Linux 块缓存实践
7.1 Embedded Linux 中的缓存问题
嵌入式 Linux 经常遇到：断电文件损坏
根本原因通常是 dirty page 尚未回写。例如：
并不意味着数据已经真正写入 Flash。
因此工业系统中通常需要：fsync(fd);强制刷盘。
但 fsync 会显著降低性能，因为它需要等待：
page cache ↓bio ↓device flush
全部完成。因此很多工业设备会在“可靠性”与“性能”之间做权衡。
7.2 现代 Linux 存储架构趋势
Linux 块缓存机制正在逐渐变化。传统架构强调：page cache + block layer，而现代高性能存储开始出现：DAX，SPDK io_uring userspace storage stack目标是减少：page copy context switch block layer overhead，例如 DAX 可以直接绕过 page cache 访问持久化内存。
Linux 块缓存机制本质上是“以内存隐藏存储延迟”的系统工程。理解 page cache、dirty page、bio、writeback 后，再学习 ext4、F2FS、NVMe、io_uring 等架构，会发现 Linux 整个存储子系统都建立在“缓存 + 异步 + 合并”这三个核心思想之上。
建了一个嵌入式Linux技术群，专门聊难题分析和求职面试，欢迎大家一起加入，共同解决工作中的疑难杂症问题
