我正在尝试对具有多个子卷的 BTRFS 文件系统进行重复数据删除。它总共保存了大约 3.5 TB 的数据，我预计在重复数据删除后该数据将略多于该大小的一半。我最关心的是重复文件，而不是单个块（但我仍然想对小文件进行重复数据删除）。文件大小差异很大。驱动器当前处于维护模式，即在进行重复数据删除时不会对文件进行任何更改。
duperemove运行在具有 16 GB 物理内存、8 GB 交换空间的系统上。由于数据量大，我使用哈希文件，也因为它允许我随时中断和恢复。
我最初的运行是使用默认的块大小。索引编制大约需要 28 天才能完成（生成一个 21 GB 的哈希文件），之后系统又花了 8 天的时间将重复的哈希值加载到内存中，然后几乎完全耗尽内存并变得无响应。 （duperemove大部分时间内存使用量一直在 12-14 GB 之间波动，但内存不断被填满，尽管我没有看到系统上任何进程的内存使用量增加。）
我添加额外内存的选择是有限的。几乎我唯一的选择是在 USB 驱动器上添加额外的交换空间，这给本已昂贵的交换机制又增加了性能损失。尽管如此，我还是通过这种方式添加了另外 32 GB f 交换空间，只是为了防止用完。
但是，我还没有尝试使用不同的块大小（常见问题解答几乎没有任何相关信息）。基本上，我的问题是：
- 我应该如何选择块大小以防止内存不足？
- 我应该如何选择块大小以获得最佳性能，同时仍保持良好的重复数据删除率？ （我不想再等一个月才能进行一次测试运行，但我可以承受浪费一两千兆字节的磁盘空间。）
- 交换的性能损失是什么？它是否有助于减少内存使用量以便不需要交换，或者不交换的好处是否会被其他东西抵消？
- 我可以重复使用使用不同块大小创建的现有哈希文件吗？如果是这样，如果所有内容都已经散列，那么更改块大小会有任何影响吗？
答案1
不是一个完整的答案，但对于块大小：在测试数据集上，我发现 64K 块大小的重复数据删除仍然在合理的时间内完成。 4K 适用于较小的场景，但不适用于较大的场景。对于 300-500G 的数据集，16K 的块大小效果很好，但使用 8K 时性能会急剧下降。
在开始摆弄块大小之前，请减少要扫描的数据量 - 这是节省资源的最佳方法：
- 如果您有多个快照（全部都经过重复数据删除或只读），则扫描所有快照不会有任何好处 – 一个就足够了。最好是最新的，或者是您要保存时间最长的
- 如果您对重复项的位置有一个粗略的预期（例如，大部分是相同的路径），请将您的文件系统划分为更小的部分，以最小化“跨部分”重复项，并按部分删除重复项。排除那些您预计不会出现大量重复的部分。
最后，测试一下。从 128K（默认）开始，然后从那里向上或向下工作（每次都使用新的哈希文件）：如果完成时间仍然可以接受，则不会耗尽内存，请使用较小的块大小（一半或四分之一）重复上一篇的内容）。如果需要太多时间或内存，请中止并将块大小增加 2 或 4 倍。您可以采用的最低值是底层文件系统的块大小stat -f /path/to/mountpoint（btrfs 的默认块大小为 4K）。
至于对同一组数据进行多次运行：由于较大的块已经进行了重复数据删除，第二次和后续运行将更快地完成并使用更少的内存，但也会节省驱动器上的空间。