是的，虽然不是很大，但是我需要使用一些东西，其中大约60,000个平均大小为30kb的文件存储在一个目录中（这是一个要求，因此不能简单地分成文件数量较少的子目录）。
这些文件将被随机访问，但是一旦创建，将不会写入同一文件系统。我目前正在使用Ext3，但是发现它非常慢。有什么建议么？
Answers:
您应该考虑使用XFS。它在文件系统和目录级别都支持大量文件，并且由于B +树数据结构，即使有大量条目，性能也保持相对一致。
本文的作者深入研究了文件数量大的文件系统上的一些性能问题，并对各种文件系统ext3，ext4和XFS的性能进行了很好的比较。这可以作为幻灯片放映。http://events.linuxfoundation.org/slides/2010/linuxcon2010_wheeler.pdf
ext3目录中的许多文件已在姊妹站点stackoverflow.com上进行了详细讨论。
在我看来，ext3上一个目录中的60 000个文件远非理想，但根据您的其他要求，这可能就足够了。
好。我使用ReiserFS，XFS，JFS，Ext3（启用了dir_hash）和Ext4dev（2.6.26内核）进行了一些初步测试。我的第一印象是，它们的运行速度都足够快（在我强大的工作站上）-事实证明，远程生产机器的处理器速度相当慢。
即使在初次测试时，我也对ReiserFS感到有些奇怪，因此将其排除在外。看来JFS的CPU需求比所有其他CPU少33％，因此将在远程服务器上进行测试。如果性能足够好，我会用它。
我正在编写一个应用程序，该应用程序也存储很多文件，尽管我的文件更大，但我有1000万个文件将拆分到多个目录中。
ext3速度较慢，主要是由于默认的“链接列表”实现。因此，如果一个目录中有很多文件，则意味着打开或创建另一个目录的速度将越来越慢。有一种叫做htree索引的东西可用于ext3，据报道它可以大大改善。但是，它仅在创建文件系统时可用。看到这里：http : //lonesysadmin.net/2007/08/17/use-dir_index-for-your-new-ext3-filesystems/
由于由于ext3的限制，无论如何您都必须重建文件系统，因此我建议您考虑使用ext4（或XFS）。我认为ext4使用较小的文件会更快一些，并且重建速度也更快。据我所知，ext4上的Htree索引是默认的。我对JFS或Reiser确实没有任何经验，但是我听说以前有人建议这样做。
实际上，我可能会测试几个文件系统。为什么不尝试ext4，xfs和jfs，看看哪一个提供最佳的整体性能？
开发人员告诉我的可以加快应用程序代码速度的事情不是执行“ stat + open”调用，而是执行“ open + fstat”。第一个明显慢于第二个。不知道您是否对此有任何控制或影响。
在stackoverflow上查看我的帖子。 在Linux中存储和访问多达1000万个文件， 那里有一些非常有用的答案和链接。
使用tune2fs启用dir_index可能会有所帮助。要查看是否已启用：
sudo tune2fs -l /dev/sda1 | grep dir_index
如果未启用：
sudo umount /dev/sda1
sudo tune2fs -O dir_index /dev/sad1
sudo e2fsck -D /dev/sda1
sudo mount /dev/sda1
但是我感觉到您可能走错了路...为什么不生成一个平面索引并使用一些代码基于此随机选择。然后，您可以将子目录用于更优化的树结构。
/dev/sad1故意的，以防止复制/面食错误？
ext3及以下版本每个目录最多支持32768个文件。ext4最多支持65536个实际文件数，但可以使您拥有更多文件（它不会将它们存储在目录中，这对于大多数用户而言并不重要）。
同样，目录在ext *文件系统上的存储方式实际上是一个很大的清单。在更现代的文件系统（Reiser，XFS，JFS）上，它们存储为B树，这对于大型集而言效率更高。
文件系统可能不是满足此类要求的理想存储。某种数据库存储会更好。如果您仍然无法解决问题，请尝试将文件拆分到多个目录中，然后使用unionfs将这些目录安装（绑定）到希望所有文件都出现的单个目录中。我根本没有使用这种技术来加快速度，但是值得一试。