linux – 高目录到文件比率对XFS的影响

我们正在构建一个可能会生成非常大的XFS卷的产品,并且我正在尝试发现在给定架构的情况下我们可能遇到的扩展瓶颈.

当我们操作文件时,它们会被放置到XFS卷上的目录中.由于我们处理的文件数量,文件数量肯定会达到数千万,并且在发布后很长时间内可能会达到数亿.我们知道这一点,因为我们当前的产品就是这样的,所以我们希望下一个产品能够做到这一点是合理的.

因此,正确的早期工程是有序的.

本周文件基于以下粗略布局：

$ProjectID/$SubProjectID/[md5sum chunked into groups of 4]/file

这给目录看起来像：

0123456/001/0e15/a644/8972/19ac/b4b5/97f6/51d6/9a4d/file

分块md5sum的原因是为了避免“一个目录中的大堆文件/目录”问题.由于md5sum块,它意味着1个文件导致创建8个目录.这有非常明显的inode影响,但是我不清楚一旦我们开始扩展,这些影响将对XFS产生什么影响.

有什么影响？

顺便说一下,这是内核2.6.32,目前是CentOS 6.2(如果需要可以改变).

在测试中我使用默认值创建了xfs卷,并且没有使用任何mount-options.这是为了尽早排除问题.因为我们不需要它,所以noatime是不费脑子的.整体XFS调优是我需要解决的另一个问题,但是现在我关注我们现在设计的元数据乘数效应.

我已经知道什么是更好的解决方案,我只是不知道我是否有案例要推动改变.

由于md5sums在第一个数字中非常独特,并且单个子项目很少超过500万个文件,因此在我看来,我们只需要前两个块.哪个会产生如下布局：

0123456/001/0e15/a644/897219acb4b597f651d69a4d/file

完全完整的第一级和第二级将在每个第一级目录中具有216个第一级目录和216个第二级目录,对于该卷上的总共232个目录.

因此,假设的500万个文件子项目将具有216个第一级目录,每个目录中大约76(/ – 2)个第二层目录,以及每个第二层目录中的一个或两个第三层目录.

这种布局提高了元数据的效率.我只是不知道是否值得努力改变现在的状况.

除了XFS之外,没有任何重要建议可以扩展到此.我在2003年开始使用文件系统,因为我需要解决一个可以在一个目录中轻松拥有800,000个文件的应用程序. ext2和ext3通常会在这些文件系统中的操作中出现问题.

这很大程度上取决于您的应用程序以及它如何访问文件(目录遍历等).

如果这一切都在一台服务器上,我会根据您对大量元数据操作的期望来查看外部SSD日志.但你知道那一部分.我仍然会使用第二个md5示例推动重组.我的意思是,这是重构的好时机,对吧？