在Linux中存储和访问多达1000万个文件

我正在编写一个应用程序,需要存储大量的文件大约1000万。

他们现在用一个UUID命名,每个大概4MB,但总是相同的大小。 从这些文件读取和写入将始终是连续的。

2个主要问题我正在寻找答案:

1)哪个文件系统最适合这个。 XFS还是ext4? 2)是否有必要将文件存储在子目录下,以减less单个目录中文件的数量?

对于问题2,我注意到人们试图发现XFS可以存储在单个目录中的文件数量限制,并且没有发现超过数百万的限制。 他们注意到没有性能问题。 那在ext4下呢?

search人员做类似的事情,有人build议存储索引节点号码作为文件的链接,而不是性能的文件名(这是在我也使用的数据库索引)。 但是,我没有看到一个可用的API通过inode编号打开文件。 这似乎更多的是提高ext3下的性能的build议,我不想用这种方式。

什么是ext4和XFS限制? 从一个到另一个有什么性能好处,你能看到在我的情况下使用ext4超过XFS的原因吗?

Solutions Collecting From Web of "在Linux中存储和访问多达1000万个文件"

你一定要将文件存储在子目录中。

EXT4和XFS都使用高效的查找方法来处理文件名,但是如果您需要在ls之类的目录上运行工具,或者find您将会非常高兴将这些文件设置为可管理的1,000 – 10,000个文件块。

inode号码的目的是提高EXT文件系统的顺序访问性能。 元数据存储在inode中,如果您不按顺序访问这些inode,则元数据访问将随机化。 通过以inode顺序读取文件,您也可以按顺序访问元数据。

现代文件系统可以让你在同一个目录中存储1000万个文件。 但是工具(ls和它的朋友)不能正常工作。

我建议把一个级别的目录,一个固定的数量,可能是1,000个目录,并把文件放在那里(10,000个文件是容忍的外壳和“ls”)。

我见过创建多级目录的系统,这实际上是不必要的,增加了inode消耗,使得遍历速度变慢。

10M文件也不应该真的成为一个问题,除非你需要对它们进行批量操作。

我希望你将需要修剪旧文件,但像“tmpwatch”的东西可能会工作得很好,10M文件。