我们正在构build一个可能会产生非常大的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个目录被创build。 这对inode有着非常明显的影响，但我不清楚一旦我们达到规模，对XFS的影响会是什么。
有什么影响？
顺便说一下，这是内核2.6.32，目前CentOS 6.2（如果需要可以更改）。
在testing中，我已经创build了默认的xfs卷，并没有使用任何安装选项。 这是为了早日排除问题。 因为我们不需要它，所以noatime是一件简单的事情。 总体来说，XFS调整是我需要解决的另一个问题，但现在我担心我们现在devise的元数据乘数效应。
我已经知道一个更好的解决scheme将是什么，我只是不知道是否有案件推动改变。
由于md5sums在第一个数字中是非常独特的，单个子项目很less超过500万个文件，所以在我看来，我们只需要前两个数据块。 这将产生如下的布局：
0123456/001/0e15/a644/897219acb4b597f651d69a4d/file
完全完整的第一级和第二级将在每个第一级目录中具有2 16个第一级目录和2 16个第二级目录，卷上总共有2 32个目录。
因此假设的5百万个文件子项目因此将具有2 16个第一级目录，每个大约76（+/- 2）个二级目录以及每个第二级目录中的一个或两个第三级目录。
这种布局有更多的元数据效率。 我只是不知道是否值得努力改变现在的情况。
除了XFS之外，没有其他重要的build议可以扩展到这个范围。 我在2003年开始使用文件系统，因为我需要解决一个应用程序，该应用程序可以在一个目录中容易地拥有80万个文件。 ext2和ext3会经常在这些文件系统中的操作中崩溃。
这很大程度上取决于您的应用程序以及它如何访问文件（目录遍历等）。
如果这一切都在一台服务器上，那么我会根据您期望的大量元数据操作来查看外部SSD日志。 但你知道这一部分。 我仍然会用第二个md5的例子来推动重组。 我的意思是，这是重构的好时机，对吧？