数百万个小文件的文件系统

在以下情况下，您将选择哪种Linux文件系统以获得最佳速度：

• 一亿个档案
• 平均约2k文件大小
• > 95％的读取权限
• 相当随机的访问
• 高并发（> 100个进程）

注意：文件存储在深层次树中，以避免目录过大。每个叶目录包含大约一千个文件。

您将如何进行基准测试？

以下是一些比较所有主要linux FS和bonnie ++的结果，您可以将它们用作起点。

在随机搜寻方面，Reiser胜出，其次是EXT4，其次是JFS。我不确定这是否与目录查找完全相关，但是似乎可以作为一个指标。您必须为此专门进行自己的测试。在缺少文件创建时间的情况下，EXT2击败了一切，这可能是由于缺少日志，而EXT4却击败了除Reiser之外的所有内容，由于hans reiser的当前状态，您可能不想使用它。

您可能要研究支持NCQ的驱动器，并确保已安装安装程序以使用它。在繁重的寻找下，它应该可以提速。

最后，确保您的机器有大量的内存。由于文件不经常更新，因此如果有可用空间，Linux最终会将它们中的大多数缓存到ram中。如果您的使用模式正确，则将大大提高速度。

我同意安德鲁所说的大部分内容，只是我建议使用Reiser4或更旧的（但得到更好的支持）ReiserFS。正如这些测试（以及ReiserFS的文档）所表明的那样，它专门用于您所要询问的情况（大量的小文件或目录）。我过去曾在Gentoo和Ubuntu中使用ReiserFS，没有任何问题。

至于Hans Reiser的状态，我认为这与文件系统本身的代码或稳定性无关。Reiser4甚至由DARPA和Linspire共同赞助，因此尽管我同意还不确定Reiser文件系统的进一步开发，但我认为这并不是决定是否应使用它的决定性因素。

我知道这不是您问题的直接答案，但是在这些情况下，我认为数据库可能更适合托管此问题。小文件可以以二进制格式存储在数据库表中，并可以在wil处检索。使用这些文件的软件应该能够支持此操作...

Unix StackExchange上的某人创建了一个基准测试（带有源代码）来测试这种情况：

问：什么是存储大量小文件（HDD，而不是SSD）的最高性能Linux文件系统？

最好的读取性能似乎来自ReiserFS。

以我的经验，ext2会将ext4吹出小文件。如果您不关心写入完整性，那就太好了。例如，subversion创建了很多很多小文件，这些文件使ext4和其他文件系统（XFS）阻塞（运行cron作业，每半小时左右将数据从ext2同步到ext4，这实际上解决了这个问题。）

运行这些命令可使ext2更快（即使其中大多数选项会使文件系统在崩溃后变得不稳定，除非您在崩溃前运行sync）。这些命令对带有小文件的ext4几乎没有影响。

echo 15 > /proc/sys/vm/swappiness
echo 10 > /proc/sys/vm/vfs_cache_pressure
echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio
echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs
echo "2000" > /proc/sys/vm/vfs_cache_pressure

我猜是ext3（或ext4），也许JFS是不错的解决方案。我会对ext4和btrfs保持警惕（文件系统很棘手-如果要使用最新的东西，请准备好备份）。

您还可以在mkfs期间调整各种参数，以根据需要调整文件系统。

我当然会建议不要使用 XFS。并不是因为它是一个糟糕的文件系统，而是在它上面进行创建/删除是一项昂贵的操作。

为避免目录搜索出现问题，请使用智能命名方案，例如：

<first letter of id>_<last letter of id>/<id>

或类似的更复杂的方案。这将加快目录搜索的速度，从而提高整体访问速度。（这是古老的Unix技巧，我认为是从V7开始的）

大多数FS会在一个目录中阻塞超过65K个文件，我认为ext4仍然如此。Reiser文件系统没有该限制（mp3.com上的人们为此支付了费用）。不知道其他任何事情，但这就是ReiserFS的使用场景之一。