带有大量小文件的文件系统寻道性能

Question

我正在寻找建立一个由XML API提供的许多小文件的服务器。它不会对目录或顺序文件块进行大量迭代--我们谈论的是对不连续数据的大量查找。

对于单个文件的请求，BSD UFS上的寻道时间是否会随着时间的推移而降低？我知道文件系统的inode限制是基于分区/片的大小的，但是硬盘驱动器必须遍历每个文件请求的inode表，然后才能发现数据的位置。哪种文件系统可提供最佳的寻道时间性能？

另一种选择是设置2-4 4GB的"blob“文件，并有一个单独的系统，从软件中查找其中包含的文件。软件的"inode表“可以根据当前登录的用户等进行优化以进行交付。这些"inode表“可能会被缓存在RAM中，并且只与当前登录的用户相关，这样就减少了资源浪费。

从可伸缩性和维护的角度来看，这两个解决方案的排名如何？通过使用第二种解决方案，我可以期望获得什么样的性能收益？

Answer 1

最明显和经过时间验证的缓解技术是对目录(和路径名搜索策略)使用良好的分层设计，并使目录更多，每个目录中的文件更少。

Answer 2

对于带有dirhash和softupdate的最新FreeBSD版本，我没有看到每个目录几万个文件的问题。您可能不想访问超过500.000个文件。例如，删除一个包含2.500.000个文件的目录花了我三天时间。

Answer 3

我不确定我是否正确理解了您的问题，但是如果您想查找大量文件，为什么不使用RAID0或VFS文件系统上的分区mysql表呢？

编辑:据我所知，在一个文件夹中的许多文件都会降低任何 FS的速度，因为它必须维护更大的文件列表，权限和名称，数据库的设计是为了在内存中保存数据列表，并以一种非常优化的方式通过它寻找。