ReFS自带两大杀手锏特性：块克隆（Block Cloning）和写时复制（CoW，Copy on Write）。

很多人不理解这两个特性，试图用自己的方法来测试性能来判断到底哪个文件系统更快，结果就是完全没有利用到这两个特性。

首先我们说一下块克隆。

在硬盘上存储数据并不是以文件为单位而存储的，而是以块为单位来存储的。一个块一般不会很大，比如 4K。在 ReFS 中则分别支持 4K 和 64K 两种块大小。
在存储文件的时候，如果文件大小大于一个块的大小，那么文件就会被分成多个块存储到硬盘上，然后在文件系统的元数据里使用一个索引来记录每个文件都放到了哪些块上。

当我们复制文件的时候，不支持块克隆的文件系统需要逐个读取原文件的块数据，然后写到新的空白的块中，意味着有 1G 的文件就至少需要读取 1G 的数据再写入 1G 的数据，这样才能完成一次复制操作。
而 ReFS 支持块克隆，允许多个文件共享相同的逻辑簇，因此复制文件的操作从读取原文件数据再写入新文件数据的操作，变成了只需要在文件系统的元数据里添加一个文件记录并给对应的块的计数器加一，免去了全部的数据读取和写入的操作。

下面这个示意图展示了把 1.zip 复制成 2.zip 在 NTFS 和 ReFS 上的不同，其中红色和青色代表了各自文件及其块，块上的数字表示被引用的次数。




然后我们再说一下写时复制。

前面说了块克隆可以让多个文件共享同样的块，但如果其中一个文件的内容发生了修改要怎么办呢？总不能让一起共享块的那些文件全都发生更改。此时写时复制就派上用场了。
文件系统会在块的数据发生更改的那一刻才会真正的把数据复制到一个新块上然后再进行修改，这样修改新块的数据就不会影响到原来的块的数据了。


还是上面的示意图，假设现在我们要在 ReFS 上修改 2.zip 的内容，修改的部分正好位于第2个和第3个块上，那么修改之后硬盘上的数据可能会变成这样：



其中 2.zip 被修改的那两块被复制到了新的块上，而没被修改的那些块还是原样和 1.zip 继续共享。

这就是对于一般用户来说，ReFS和NTFS最大的不同！

ReFS使得你在同一个硬盘（逻辑分区）上的文件复制操作从读取和写入数据变成了简单在元数据上加一个1，并且修改复制后的文件也仅对被修改的块进行复制。
假设你的 D 盘上面有一个 500G 的大文件 D:\1.zip，此时你把文件从 D:\1.zip 复制到 D:\2.zip：如果是 NTFS 的话就得老老实实吭哧吭哧复制个大半天，因为要写入新数据，而且复制完之后你的剩余空间就少了 500G；而如果是 ReFS 的话，不好意思只需要更新元数据上的计数器，复制操作几乎瞬间就能完成，并且复制之后还不会多占一份空间。

这种引用计数的开销很大吗？

除了给对应块的引用计数做个加减法之外没有任何的额外开销。

Windows 11 23H2 开始已经对系统的复制文件 API 进行了改造，CopyFile 等 API 在 ReFS 上的默认行为就是块克隆。因此你在相同的分区里复制粘贴文件本质上就是块克隆，不会重复写入新的数据。不过如果你用什么 FastCopy 之类的第三方软件，很可能还没有适配于是会导致新数据被写入。

要注意的是，如果你把文件从其他分区复制到 ReFS 分区上，哪怕你复制了好几遍，这个时候都不会使用块克隆，因为写入新数据并不走块克隆，前面说的当且仅当你是把文件从 ReFS 分区复制到同一个分区里的情况。因此不存在很多人担心的所谓“如果判断两个块是否相同需要消耗大量计算资源”的这种问题。

那应用场景都在哪呢？

1. 安装游戏、软件的时候，安装程序一般会释放安装包内的内容到临时文件夹里，然后复制到要安装的位置里来完成安装。如果是 NTFS，所有的文件都需要一个个从临时文件夹复制到安装目录里，涉及到大量的数据读取和写入；而如果是 ReFS 的话，简简单单给那些文件的对应块在元数据上添加个引用计数就完事了，实际上根本不需要进行数据写入。

2. 开发软件时安装依赖、编译代码的时候，由于 ReFS 的特性，依赖包从缓存目录复制到你的代码文件夹里（比如 nodejs 的 node_modules）这种操作，可以完全省掉所有的数据写入操作，只是在元数据上做个引用计数的更新就完事。

3. 由于允许多个文件共享同样的块，因此硬盘的实际空间也能得到大量的节省，重复的文件不需要每一份都持有自己独立的数据。比如你在 ReFS 分区上创建一个巨大的文件，然后复制到这个分区的其他位置，你会发现尽管你复制了文件，但是你的磁盘剩余空间没有任何的变化，这就是因为他们的块是被共享的。

4. refsutil 自带一个 debup 命令用来去除硬盘上重复的块，本质上就是利用块克隆的技术，使得多个文件各自拥有的相同的块被合并到同一个块上，并且更新那个块的引用次数。