由于术语“块”，您的问题有点混乱，当涉及磁盘和文件系统时，这是一个非常重载的词。（但是您周围的环境有助于弄清楚。）Btrfs不处理固定大小的文件系统“块”，而是处理可变大小的“范围”。（尽管，也令人困惑，它还定义了可变大小的块区域。）ZFS处理文件系统“块”，部分或主要是因为这样做显着地解决了问题。Btrfs和ZFS都知道磁盘级别的“块”，它们本身就是抽象的。（然后，我们还有“块级存储”，这在语义上可能是不同的意思。）我可能对这些描述有些了解，不够清楚，或者不是100％准确。（如果您需要对块的主题进行澄清和100％的准确性，假装你没有读过。如果您只需要粗略的理解才能继续，那么您应该很好。）这个答案的重点不是完美地定义“块”，而是下面的讨论，这在我的操舵室中更多。
正如@killermist所写，ZFS本机支持[ZFS]块级重复数据删除。
ZFS默认未启用它。在没有足够内存的情况下打开它会严重影响性能。而且，奇怪的是，ZFS需要比“建议的每1TB存储1GB RAM”的经验法则还要多的数量，以使整个哈希表适合RAM。但是即使如此，根据硬件的不同，您仍然可以达到40 MB / s以上的写入速度。我在运行约2015年驱动器的2008年技术上得到了这一点。对于大多数档案数据，我完全可以接受。ZFS重复数据删除的最大缺点是，除了打开dedup，将所有内容复制到磁盘外，还没有一种简便的方法可以在“批处理/脱机”（或更准确地说是“带外”）模式下进行此操作。同一文件系统上的新临时目录，删除原始目录，然后将（已重复数据删除的）临时内容移回。
可以说Btrfs重复数据删除略为简化，目前只有第三方实用程序可以完成这项工作。（但是它们使用了受支持的内核API和/或受支持的cp选项；并且使用了需要它们自己的逻辑来确定重复项的任何一种方法，人们都希望这种方法永远准确无误。）尽管如此，潜在的好处是那些实用程序是“带外”。但是，对于大多数实用程序而言，代价是它们会在牺牲性能的同时降低性能-可能需要数小时，数天甚至数周才能完成。（个人而言，我宁愿处理带内ZFS重复数据删除的写入性能始终较慢的情况，而不是将自己的HDD花费数天，例如每年一次结束）。
我知道有两个Btrfs解决方案是bees和dduper，它们使用“块”（但在另一个定义中）而不是文件来处理。
例如，蜜蜂根据可用内存和可能的其他因素，在首次运行时为其自己定义一个“块”大小。（尽管我可能会歪曲它的目的，功能，机制和优点/缺点，因为我不使用它，所以我只是在最近对其进行了评估。）
Bees可以说是有点杂种，因为它可以连续运行，并且不会对磁盘造成太大的冲击-尽管从技术上讲，它还不像ZFS dedup那样“带内”。它只是在事后提取重复项，并尝试轻触重复数据。使用任意定义的块大小意味着根据设计，它将适合哈希表在RAM中。缺点（大概）是“块”中可能存在相同的范围，但是Bee可能不会重复存储，因为它们所在的“块”不同。
请记住，即使实用程序专门执行“文件”级增加了Btrfs重复数据删除（如bedup，duperemove，rmlint，和其他人），仍可能满足您的要求。我不确定，但是好像他们会那样。那是因为即使是“ cp --reflink = always”命令也没有真正对“ files”进行重复数据删除。它正在对Btrfs 范围进行重复数据删除。当重新链接的“文件”更改时，Btrfs仅将更改的范围取消重复数据删除，以其自身的唯一范围。文件的其余部分将保持重复数据删除。这就是大型重复数据删除文件仍然可以像它们自己的唯一文件一样发散，但是仍然大部分经过重复数据删除的情况。
（这也是为什么很难确定“文件”是否被重新链接的原因，因为该概念甚至都没有真正的意义。文件的所有范围本身都可能被重新链接到其他相同范围，一个确实可以是有道理的，但这恰好是一个特别棘手的问题，这就是为什么，除非Btrfs重复数据删除实用程序跟踪其已重复数据删除的内容，否则不值得尝试“检测”文件是否已重复数据删除。没有像refcount这样的属性可以进行检查。无论如何，再次进行重复数据删除会更容易。相反，确定整个文件是否以老式方式进行硬链接是微不足道的。只需检查给定inode的st_nlink计数即可。）
实际上，缺少“整个文件克隆”是所有支持“免费”快照和/或重复数据删除的CoW文件系统的固有功能，无论处理Btrfs扩展数据块，ZFS块还是其他东西，都是如此。这就是为什么任何一个都可能是您的问题的答案。（据我所知，至少还有其他三个可以或计划实现所有功能的CoW文件系统：nilfs2，bcachefs和xfs。）
尽管您没有提到这一点，但据我所知，没有重复数据删除技术可识别文件类型。换句话说，没有重复数据删除器会跳过* .jpg元数据，只考虑压缩图像数据进行重复数据删除。同样，它们都没有考虑文件魔术编号（至少用于确定要考虑重复数据删除的内容）。这可能是一个杀手级功能-尽管当然需要不断不断的定义更新。在将文件视为扩展区，块等的抽象M：M集合的同时，可能很难设计。