Copy On Write(COW) 的罪与罚

缘起

对计算机有些了解的人，或多或少会对 Copy On Write 有些听闻。我接触这个名词最早是在操作系统的进程管理中，当子进程从父进程中 fork 出来时，其和父进程共享大部分的数据，对子进程而言这块内存是只读的。通过这么做，可以避免在子进程中创建时额外分配内存带来的开销。

进程管理的细节

子进程修改内存（案例1）

如果子进程要对共享的内存进行修改，那么内存管理系统就会分配额外的一块内存，然后将父进程的内存拷贝过去，然后子进程可以在这块拷贝过去的内存进行修改。

父进程修改内存（案例2）

书本上一般没提到的是如果是父进程修改内存，那么这块内存就会被修改，这个时候子进程怎么办呢？当然还是拷贝一块内存给它啊。本部分为猜测，无代码验证。

存储卷管理领域的快照流派

在存储卷管理领域里面，有个技术叫做快照，其从本质上来说就是记录了在指定的时刻，指定卷的所有的块状态。一旦快照被创建，那么意味着后续任何对现有磁盘块的更改都必须做额外处理。处理有两种流派，一种叫做 COW（Copy On Write）另外一种叫做ROW（Redirect On Write）。

COW 流派

这种流派跟进程管理的案例2类似，如果存储发现某个磁盘块要被更改，那么它会检查所有的快照，看看这些快照是不是已经对这块磁盘空间的数据进行了拷贝，如果没有的话则进行拷贝。待拷贝完毕后，数据会写入到该磁盘块。

优缺点

• 缺点：在快照比较多的情况下，存在只针对一次写，需要发生一次读取和多次写入的情况，性能会急剧降低。快照可能会占用大量空间。
• 优点：数据的连续性比较好，对未来连续数据读取有优势。在SSD下这个优点不是很明显。

ROW 流派

这种流派跟进程管理的案例1类似，如果存储发现某个磁盘块要被更改，那么它会检查所有快照，如果发现这个磁盘块被快照使用，那么会找到一块新的空间，将数据拷贝到新空间，然后在新空间进行数据修改。这种方式和 COW 有个本质上不一样，即其最开始并不是跟踪所有分配的卷的块，而是刚开始就要跟踪写入，而写入的内容可以分布在任意地方。随着写入范围的增加，其跟踪的块会越来越多，直到和分配的卷一样大小。

优缺点

• 缺点：由于数据不是在原地修改，可能会导致数据碎片化严重，导致读取效率低下。这个缺点在 SSD 下不明显，但是在机械盘下就会成为瓶颈。
• 优点：多个快照对性能影响很有限。可以合并多个随机写入变为大块的顺序写入，性能能够较大的提高。和 COW 相比，快照比较省空间。

两大流派的补充

在这里，我为什么会认为 COW 流派以开始就跟踪所有卷内磁盘块呢？那是因为在实现中，这么做在 COW 的情况下只有些许额外的存储开销，但是能够极大的简化实现难度。无论刚开始磁盘块上有没有有意义的数据，其实也判断不出来数据是不是有意义的，最终这些磁盘块都是会被文件系统使用到，不会有空间被浪费的。
但是在 ROW 的情况下，如果以开始就假定这些磁盘块有数据，意味着后续文件系统再也没有机会往这些磁盘块写东西了。这就是一个错误的实现了。
相比而言，前者是静态的，简洁的。后者则是动态的，复杂的。

现实的实现

• LVM：COW，预先分配指定大小空间给快照，实验可以观察到快照空间的增长规律。
• ZFS，Btrfs：ROW，原来的数据不被覆盖，Btrfs 可以设置为非这种模式

现实世界中的混用

Wikipedia 中将两者都称之为 copy on write。

参考

https://en.wikipedia.org/wiki/Copy-on-write#In_computer_storage
https://storageswiss.com/2016/04/01/snapshot-101-copy-on-write-vs-redirect-on-write/
https://en.wikipedia.org/wiki/Snapshot_(computer_storage)#Implementations
https://en.wikipedia.org/wiki/ZFS#Copy-on-write_transactional_model