对于块级或更详细的重复数据删除有哪些可用的解决方案？
有基于文件的 - 采用“写入时复制”方法。
我正在寻找块级“写时复制”，因此我可以定期查找公共块，或者最好是文件的一部分，合并它们并标记 CoW 使用方式。是否有类似的东西可用，或者仍然需要创建它？我不确定 Btrfs 重复数据删除是否是块/文件/子部分级别？有 LessFS，但我不确定它提供什么级别的重复数据删除？也许还有其他解决方案？
答案1
随着块级重复数据删除的发展，我认为 ZFS 是目前无可争议的最佳实现。它确实不是为事后优化而设计的，因为它的重复数据删除（如果打开）直接内置于读/写功能中。因此，在尝试将重复数据删除表的最相关部分保留在内存中时，在负载下可能会占用一些内存，但 ZFS 善于将自身限制为消耗不超过 50% 的内存，这取决于安装的内存数量似乎相当任意（2Gb 的 50% 与 64Gb 的 50%，特别是在需要内存的用户任务很少（如果有的话）的情况下）。
根据您想要使用它的用途，您有一些选择：
印第安纳公开赛似乎有一些基于 Solaris 的不错的桌面和服务器选项
FreeBSD（自 9.0 起）内置了相当高级的 ZFS 版本（包括重复数据删除）。一个值得注意的 FreeBSD（然后是 MonoWall）派生发行版是NAS4免费，这使得制作 NAS 变得非常容易。
Linux 有几个选项，有些带有重复数据删除功能，有些则没有。既然您正在寻找重复数据删除，我见过的最值得注意的是zfsonlinux。我不确定他们的进展如何，或者他们的项目有多稳定，但它看起来绝对有希望。
至于任何具有部分块重复数据删除功能的东西，到目前为止，我还没有看到任何报告有能力做到这一点。
答案2
由于术语“块”，您的问题有点令人困惑，当涉及磁盘和文件系统时，这是一个非常重载的词。 （但是您周围的上下文有助于澄清。）Btrfs 不处理固定大小的文件系统“块”，它处理可变大小的“范围”。 （尽管令人困惑的是，它还定义了可变大小的块区域。）ZFS 处理文件系统“块”，部分或主要是因为这样做会显着更容易解决问题。 Btrfs 和 ZFS 都知道磁盘级“块”，它们本身就是抽象。 （然后我们还有“块级存储”，这在语义上可能是不同的含义。）我的这些描述可能有点偏差，不够清晰，或者不是 100% 准确。 （如果您需要关于块主题的清晰度和 100% 准确度，请假装您没有阅读该内容。如果您只需要粗略的理解才能继续，那么您应该很好地继续。）这个答案的要点不是完美定义“块”，但下面的讨论在我的驾驶室中更多。
正如 @killermist 所写，ZFS 本身支持 [ZFS] 块级重复数据删除。
ZFS 中默认情况下未启用它。在没有足够内存的情况下打开它会严重影响性能。此外，据传，ZFS 需要比“每 1tb 存储 1gb RAM”推荐的经验法则更多的数量，才能将整个哈希表放入 RAM。但即便如此，根据硬件的不同，您仍然可以获得高达 40 MB/s 的写入速度。我在运行 ~2015 时代驱动器的 2008 时代技术上得到了这一点。对于大部分档案数据来说，我完全可以接受。 ZFS 重复数据删除的最大缺点是，除了打开重复数据删除、将所有内容复制到同一文件系统上的新临时目录，删除原始目录，然后将（现已删除重复的）临时内容移回原处。 （除了删除旧文件可能比初始复制/重复数据删除操作花费更长的时间。）我通常所做的是等到我必须定期重新构建阵列以更改基本布局，然后从旧阵列复制到新的，已启用重复数据删除。
Btrfs 重复数据删除可以说有点粗略，目前只有第三方实用程序可以完成这项工作。 （但是它们要么使用受良好支持的内核 API，和/或受良好支持的 cp 选项；并且无论哪种方式都需要自己的逻辑来确定重复项，人们希望这是完全准确的。）不过，一个潜在的好处是这些实用程序是“带外”的。然而，大多数公用事业公司的成本是，他们在不断敲击的过程中牺牲了性能——这可能需要数小时、数天甚至数周才能完成。 （就我个人而言，我宁愿处理带内 ZFS 重复数据删除的写入性能始终较慢的情况，也不愿连续数日锤击我的 HDD，比如每年结束一次。）
我知道有两个 Btrfs 解决方案处理“块”（但在另一个定义中）而不是文件，它们是蜜蜂， 和杜普。
例如，蜜蜂在第一次运行时根据可用内存和可能的其他因素为自己任意定义“块”大小。 （虽然我可能歪曲了它的目的、特性、机制和优点/缺点，因为我不使用它，我最近才将它作为一种选择进行评估。）
Bees 可以说有点混合，因为它被设计为连续运行，并且不会那么用力地敲击磁盘 - 尽管在技术上仍然不像 ZFS 重复数据删除那样“带内”。它只是在事后拾取重复项，并尝试轻轻一触即可删除重复项。使用任意定义的块大小意味着，根据设计，它将适合 RAM 中的哈希表。缺点（大概）是“块”中可能存在相同的范围，但 Bees 可能不会进行重复数据删除，因为它们所在的“块”在其他方面是不同的。
请记住，即使是专门执行“文件”级 Btrfs 重复数据删除的实用程序（例如床上用品,杜佩删除,林特等），仍然可以满足您的要求。我不能确定，但看起来他们会的。这是因为即使是“cp --reflink=always”命令也不能真正删除“文件”的重复数据。它正在对 Btrfs 进行重复数据删除范围。当重新链接的“文件”发生更改时，Btrfs 仅将更改的范围取消重复数据删除到其自己的唯一范围。文件的其余部分仍然经过重复数据删除。这就是大的重复数据删除文件仍然可以像它们自己的独特文件一样分散，但仍然大部分被重复数据删除。
（这也是为什么很难确定“文件”是否被重新链接，因为这个概念甚至没有真正的意义。文件的所有内容范围本身可能会被重新链接到其他相同的范围，这个概念确实有意义，但巧合的是，这是一个特别难以回答的问题。这就是为什么，除非 Btrfs 重复数据删除实用程序跟踪它已经删除重复的内容，否则不值得尝试“检测”文件是否已经删除重复。没有像引用计数这样的属性可供检查。无论如何，再次删除重复数据会更容易。相比之下，确定整个文件是否以老式方式硬链接是微不足道的。只需检查给定 inode 的 st_nlink 计数。）
事实上，缺乏“整个文件克隆”是所有支持“免费”快照和/或重复数据删除的 CoW 文件系统的固有特征，无论是处理 Btrfs 范围、ZFS 块还是其他东西，都是如此。这就是为什么其中任何一个都可以回答您的问题。 （据我所知，至少还有其他三个 CoW 文件系统可以或计划能够完成所有这些工作：nilfs2、bcachefs 和 xfs。）
尽管您没有提到这一点，但据我所知，没有重复数据删除技术可以识别文件类型。换句话说，没有重复数据删除器知道跳过 *.jpg 元数据，只考虑压缩图像数据进行重复数据删除。同样，他们都没有考虑文件幻数（至少在确定重复数据删除时要考虑什么）。这可能是一个杀手级功能——尽管肯定需要不断的、持续的定义更新。而且将文件视为扩展区、块等的抽象 M:M 集合时，设计起来可能非常困难。