现代文件系统中的数百万个文件对性能有何影响？

Question

假设我们正在使用 ext4（启用 dir_index）来托管大约 3M 文件（平均大小为 750KB），我们需要决定我们将使用什么文件夹方案。

在第一个解决方案中，我们将哈希函数应用于文件并使用两级文件夹（第一级为 1 个字符，第二级为 2 个字符）：因此filex.for哈希等于abcde1234，我们将其存储在 /path / a/bc /abcde1234-filex.for。

在第二种解决方案中，我们对文件应用哈希函数并使用两级文件夹（第一级为 2 个字符，第二级为 2 个字符）：因此filex.for哈希等于abcde1234，我们将其存储在 /path / ab/de /abcde1234-filex.for。

对于第一个解决方案，我们将采用以下方案/path/[16 folders]/[256 folders]，每个文件夹（文件所在的最后一个文件夹）平均有 732 个文件。

而在第二个解决方案，我们将有/path/[256 folders]/[256 folders]与平均每个文件夹45页的文件。

考虑到我们要从这个方案中写入/取消链接/读取文件（但主要是读取）（基本上是 nginx 缓存系统），如果我们选择一个或其他解决方案，它在性能方面是否重要？

另外，我们可以使用哪些工具来检查/测试此设置？

Answer 1

创建这种目录结构的原因是文件系统必须在目录中定位文件，目录越大，操作越慢。

慢多少取决于文件系统设计。

ext4 文件系统使用B 树来存储目录条目。对该表的查找预计需要O(log n)时间，大部分时间比 ext3 和以前的文件系统使用的原始线性表要少（如果不是，则目录太小，无法非常重要）。

XFS 文件系统使用B+树代替。与哈希表或 B 树相比，它的优势在于任何节点都可能有多个子节点b，其中在 XFS 中b变化并且可以高达 254（或根节点为 19；这些数字可能已经过时）。这为您提供了O(log _b n)的时间复杂度，这是一个巨大的改进。

这些文件系统中的任何一个都可以处理单个目录中的数万个文件，在具有相同 inode 数量的目录上，XFS 比 ext4 快得多。但是您可能不想要具有 3M 节点的单个目录，因为即使使用 B+树，查找也可能需要一些时间。这就是首先以这种方式创建目录的原因。

至于您提出的结构，您提供的第一个选项正是 nginx 示例中显示的内容。它在任一文件系统上都表现良好，但 XFS 仍将具有一些优势。第二个选项的性能可能稍好或稍差，但它可能会非常接近，即使在基准测试中也是如此。

Answer 2

根据我的经验，缩放因子之一是给定哈希名称分区策略的 inode 的大小。

您建议的两个选项为每个创建的文件创建最多三个 inode 条目。此外，732 个文件将创建一个仍然小于通常 16KB 的 inode。对我来说，这意味着任何一个选项都将执行相同的操作。

我为你的简短哈希鼓掌；我以前使用过的系统根据该字符串获取给定文件的 sha1sum 和拼接目录，这是一个更难的问题。