我们正在构建一个可能会生成非常大的 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 卷，并且没有使用任何挂载选项。这是为了尽早解决问题。noatime很简单，因为我们不需要它。总体 XFS 调整是我需要解决的另一个问题，但现在我担心我们现在设计的元数据乘数效应。
我已经知道更好的解决方案是什么，我只是不知道我是否有理由推动改变。
由于 md5sums 的前几个数字非常独特，并且单个子项目很少超过 500 万个文件，在我看来，我们只需要前两个块。这将产生如下布局：
0123456/001/0e15/a644/897219acb4b597f651d69a4d/file
一个完整的第一级和第二级在每个第一级目录中将有 2 16个一级目录和 2 16个二级目录，卷上总共有 2 32 个目录。
因此，假设的 500 万个文件子项目将有 2 16个一级目录，每个目录中大约有 76 (+/- 2) 个二级目录，每个二级目录中有一个或两个第三级目录。
这种布局的元数据效率更高。我只是不知道是否值得努力改变现在的情况。