目录中的文件数量多得可笑

Question

我的雇主收购了一家公司，该公司有一款特定的软件，该软件在一个目录中存储了大量 PDF 和 PNG 文件。当我第一次从 AWS 复制它时，大约有 1150 万个文件。现在这个数字已经接近 1300 万，而且性能——说得客气点——很差劲。

目录必须在四台服务器之间共享，因此将 LUN 连接到每台服务器是行不通的。当我进行原始复制时，我尝试了 ext4 文件系统，但在大约 1000 万时，我开始遇到严重问题。我考虑尝试 XFS，但时间紧迫，我只能编译它们。我最终将它们放在具有 UFS 文件系统并运行 BSD 的 Dell Isilon 上。目录使用 NFS 导出。

如果决定只为此构建一个新的 NFS 服务器，那么哪些文件系统能够处理如此多的文件，并且在检索时仍能提供不错的性能？我知道最好的解决方案是将其分解，这样一个目录中就不会有那么多文件，但在快速、便宜和优质的竞争中，优质总是排在最后。

Answer 1

由于目录元数据非常庞大，一个目录中的文件数量过多最终会变得非常慢，无法使用。快速存储和文件系统选择只能起到有限的作用。

将此树重构为多个目录。计算内容的统一哈希值，并将其存储在以前几位数字命名的目录中。对于 SHA da39a3ee5e6b4b0d3255bfef95601890afd80709，将其存储在 da/39a3ee5e6b4b0d3255bfef95601890afd80709.png

或者，应用程序可以处理对象存储而不是常规文件。S3 协议或类似协议。作为不同的 API，它可能会丢失本地文件系统的 dentry 语义。内容寻址支持重组或扩展存储，而无需更改应用程序查找 blob 的方式。

重组和应用程序变更并不是您想听到的。但实际上无法避免，需要一种更智能的方式来存储 blob 才能进行如此大规模的扩展。