我们正在构建一种可能会生成非常大的 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 调优是我需要解决的另一个问题，但现在我担心的是我们现在设计的元数据乘数效应。
我已经知道更好的解决方案是什么，我只是不知道是否有理由推动改变。
由于 md5sum 的前几位数字非常独特，并且单个子项目很少超过 500 万个文件，因此我认为我们只需要前两个块。这将产生如下布局：
0123456/001/0e15/a644/897219acb4b597f651d69a4d/file
完全完整的第一级和第二级将具有 2 16 个第一级目录和每个第一级目录中 2 16 个第二级目录，卷上总共有 2 32 个目录。
因此，假设的 500 万个文件子项目将有 2 16 个一级目录，每个一级目录大约有 76 (+/- 2) 个二级目录，每个二级目录中有一到两个第三级目录。
这种布局的元数据效率更高。我只是不知道是否值得努力改变现在的情况。
答案1
除了 XFS 之外没有其他主要建议应该扩展到这个规模。我从 2003 年开始使用文件系统，因为我需要处理一个可能在一个目录中包含 800,000 个文件的应用程序。ext2 和 ext3 在这些文件系统中的操作中经常会失败。
这在很大程度上取决于您的应用程序以及它如何访问文件（目录遍历等）。
如果这一切都在一台服务器上，我会根据您对大量元数据操作的预期来查看外部 SSD 日志。但你知道那部分。我仍然会推动使用第二个 md5 示例进行重组。我的意思是，这个是现在是重构的好时机，对吧？