![哪些因素会影响理想的 s3ql --max-obj-size 值?](https://linux22.com/image/593980/%E5%93%AA%E4%BA%9B%E5%9B%A0%E7%B4%A0%E4%BC%9A%E5%BD%B1%E5%93%8D%E7%90%86%E6%83%B3%E7%9A%84%20s3ql%20--max-obj-size%20%E5%80%BC%EF%BC%9F.png)
我试图理解创建时使用的 --max-obj-size 值的所有相关含义s3ql文件系统。我还没有找到关于此选项含义的完整描述,但已经能够从文档和讨论组中拼凑出一些信息。
主要是,我发现了使用更大的 --max-obj-size 值的理由,这让我感到疑惑,为什么不使用任意大的值(10mb?100mb?1gb?):
- 值越小,意味着使用的“inode”越多,sqlite 数据库的性能越差(因为相同数量的文件需要更多的 inode 条目)
- 较小的值可能会损害吞吐量(尤其是顺序读取)。
从 1.8 版本开始变更日志:
事实上,较小的 S3QL 块大小确实不是在存储大量小文件时,较小的块大小比较大的块大小没有任何优势。然而,在存储较大的文件时,较小的块大小会严重降低性能。这是因为 S3QL 实际上是在使用动态块大小,而 --blocksize 值仅指定了上限。
到目前为止,我发现或想象到的较小块大小的唯一优势是:
- 重写文件的一部分所需的带宽更少
- 可能更好的重复数据删除
--min-obj-size 选项不会影响重复数据删除。重复数据删除发生在块分组之前。
--max-obj-size 会影响重复数据删除,因为它隐式地确定了块的最大大小。
成立这里:
有人可以提供一下在创建 s3ql 文件系统时选择较大或较小的 --max-obj-size 时所做的权衡的总结吗?