核心原理：Copy-on-Write (CoW) 机制详解

写时复制，英文叫 Copy-on-Write，简称 CoW。这名字听起来有点学术，其实说白了就是四个字——懒。不到万不得已，绝不动手复制数据。

我刚开始接触存储系统时，总觉得 CoW 是个很“重”的操作。后来踩过几次坑才明白，它恰恰是为了“轻”而生的。你想想看，一个 1TB 的卷，如果每次做快照都要完整拷贝一遍，那磁盘和带宽早就被撑爆了。CoW 的思路就是：先让快照和源数据共享同一份物理数据，只有当某个数据块要被修改时，才把原始块复制一份出来。

触发条件：什么时候触发写时复制？

不是每次写入都会触发 CoW。只有满足以下两个条件，系统才会执行复制动作：

  • 条件一：该数据块已被快照引用。也就是说，这个块在快照创建时是“冻结”的。
  • 条件二：当前是首次对该块进行写入。如果之前已经触发过 CoW，后续写入直接覆盖新副本即可。

嗯，这里要注意一个细节：读操作永远不会触发 CoW。读就是读，不管读的是源卷还是快照，都直接走共享数据路径。

核心判断逻辑：CoW 触发 = 该块被快照引用 + 该块尚未被写时复制过

数据流：一次完整的 CoW 写入过程

我习惯把 CoW 的数据流拆成 5 个步骤。这样理解起来更清晰：

  1. 应用发起写入请求：要修改源卷上的数据块 X。
  2. 检查引用计数：系统发现块 X 的引用计数 > 1（被快照引用了）。
  3. 分配新物理块：在存储池中分配一个空闲块 Y。
  4. 复制原始数据：将块 X 的内容完整拷贝到块 Y。
  5. 更新映射表：快照的指针指向块 Y，源卷的指针保持不变（或指向新写入的数据）。

我曾经在调试一个生产环境的性能抖动问题时，发现 CoW 的步骤 4 是最大的瓶颈。如果原始块很大（比如 4MB），复制耗时就会明显增加。后来我们做了个小优化——把大块拆成小块，CoW 的粒度从 4MB 降到 64KB，抖动问题就解决了。

我的经验：CoW 的粒度越小，写放大越少，但元数据开销越大。64KB 到 256KB 之间是个比较平衡的选择。

CoW 与 RoW 的对比

说到 CoW，就不得不提它的“兄弟”RoW（Redirect-on-Write，重定向写）。两者思路正好相反：

特性 CoW（写时复制） RoW（重定向写）
写入方式 先复制旧数据，再写入新数据 新数据直接写入新位置，旧数据不动
读性能 源卷读性能稳定（数据在原地） 源卷读可能变慢（需要查映射表）
写放大 每次首次写入多一次读+写 没有复制开销，但映射表更新频繁
适用场景 读多写少的快照场景 写频繁的虚拟化磁盘场景

我个人更倾向在增量快照场景中使用 CoW。为什么？因为快照的本质是保留历史状态，CoW 让源卷的物理布局保持不变，读性能不会退化。RoW 虽然写放大更小，但源卷的数据块会散落在各处，时间长了碎片化严重。

CoW 的元数据管理

CoW 离不开一张核心的映射表。这张表记录了每个逻辑块地址（LBA）对应的物理块地址（PBA），以及引用计数。

// 简化版的 CoW 映射表结构
struct cow_map_entry {
    uint64_t lba;           // 逻辑块地址
    uint64_t pba;           // 物理块地址
    uint32_t ref_count;     // 引用计数
    uint8_t  flags;         // 状态标志（是否已复制等）
};

引用计数是关键。当 ref_count > 1 时，说明该物理块被多个快照共享。每次触发 CoW，ref_count 减 1。当 ref_count 降到 1 时，该块就不再是共享状态了。

我曾经踩过的坑：引用计数溢出。早期我们用 uint8_t 存 ref_count，结果一个块被 256 个快照引用后就溢出了。后来统一改成 uint32_t，再也没出过问题。

CoW 的写放大问题

写放大是 CoW 逃不开的话题。一次 4KB 的写入，如果触发了 CoW，实际 IO 可能是：

  • 读原始块（4KB）
  • 写新副本（4KB）
  • 写新数据（4KB）

总共 12KB 的 IO，写放大系数是 3x。这还只是数据面，元数据更新还没算进去。

怎么优化？我分享两个实战经验：

  1. 合并写入：如果短时间内对同一块区域有多次写入，可以延迟 CoW，等写入稳定后再触发。但要注意延迟时间不能太长，否则快照一致性会受影响。
  2. 预分配副本池：提前分配一批空闲块，CoW 时直接从池中取，减少分配耗时。我在一个项目中用这个优化，把 CoW 的 P99 延迟从 5ms 降到了 1.2ms。

CoW 数据流全景图

下面这张图展示了 CoW 的完整数据流。我建议你仔细看看箭头走向，尤其是“快照指针”和“源卷指针”的变化：

CoW 写时复制数据流全景图 应用写入请求 检查引用计数 > 1？ 否（直接写入） 是（触发 CoW） 分配新物理块 Y 复制块 X → 块 Y 更新映射表 & 引用计数 写入新数据到源卷 关键点：快照指针指向块 Y（旧数据），源卷指针指向新写入的数据

CoW 的优缺点总结

没有银弹。CoW 有它的优势，也有它的短板。我列个清单，方便你快速对照：

  • 优点：
    • 快照创建极快，几乎是瞬间完成（只记录元数据）
    • 源卷读性能不受影响，数据布局不变
    • 空间效率高，只存储变化的数据块
  • 缺点：
    • 首次写入有额外延迟（复制开销）
    • 写放大问题，影响写入吞吐
    • 元数据管理复杂，引用计数需要精确维护

我在一个金融核心系统里见过 CoW 的极限场景——每天 2000 次快照，每个快照保留 7 天。引用计数表膨胀到几百万条。后来我们做了分层映射表，热数据用内存存，冷数据落盘，才把元数据查询延迟控制在 10 微秒以内。

CoW 的原理看起来简单，但真正在生产环境用好它，需要你对 IO 路径、元数据结构和性能瓶颈有深刻理解。这一章先把基础打牢，后面我们会深入 CoW 的工程实现细节。

← 上一章 📖 返回目录 下一章 →