![为 duperemove 选择正确的块大小](https://linux22.com/image/210156/%E4%B8%BA%20duperemove%20%E9%80%89%E6%8B%A9%E6%AD%A3%E7%A1%AE%E7%9A%84%E5%9D%97%E5%A4%A7%E5%B0%8F.png)
我正在尝试对具有多个子卷的 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)。
至于对同一组数据进行多次运行:由于较大的块已经进行了重复数据删除,第二次和后续运行将更快地完成并使用更少的内存,但也会节省驱动器上的空间。