我们正在构建一个可能会生成非常大的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)个第二层目录,以及每个第二层目录中的一个或两个第三层目录.
这种布局提高了元数据的效率.我只是不知道是否值得努力改变现在的状况.
