![目录中的文件数量多得可笑](https://linux22.com/image/758624/%E7%9B%AE%E5%BD%95%E4%B8%AD%E7%9A%84%E6%96%87%E4%BB%B6%E6%95%B0%E9%87%8F%E5%A4%9A%E5%BE%97%E5%8F%AF%E7%AC%91.png)
我的雇主收购了一家公司,该公司有一款特定的软件,该软件在一个目录中存储了大量 PDF 和 PNG 文件。当我第一次从 AWS 复制它时,大约有 1150 万个文件。现在这个数字已经接近 1300 万,而且性能——说得客气点——很差劲。
目录必须在四台服务器之间共享,因此将 LUN 连接到每台服务器是行不通的。当我进行原始复制时,我尝试了 ext4 文件系统,但在大约 1000 万时,我开始遇到严重问题。我考虑尝试 XFS,但时间紧迫,我只能编译它们。我最终将它们放在具有 UFS 文件系统并运行 BSD 的 Dell Isilon 上。目录使用 NFS 导出。
如果决定只为此构建一个新的 NFS 服务器,那么哪些文件系统能够处理如此多的文件,并且在检索时仍能提供不错的性能?我知道最好的解决方案是将其分解,这样一个目录中就不会有那么多文件,但在快速、便宜和优质的竞争中,优质总是排在最后。
答案1
由于目录元数据非常庞大,一个目录中的文件数量过多最终会变得非常慢,无法使用。快速存储和文件系统选择只能起到有限的作用。
将此树重构为多个目录。计算内容的统一哈希值,并将其存储在以前几位数字命名的目录中。对于 SHA da39a3ee5e6b4b0d3255bfef95601890afd80709
,将其存储在 da/39a3ee5e6b4b0d3255bfef95601890afd80709.png
或者,应用程序可以处理对象存储而不是常规文件。S3 协议或类似协议。作为不同的 API,它可能会丢失本地文件系统的 dentry 语义。内容寻址支持重组或扩展存储,而无需更改应用程序查找 blob 的方式。
重组和应用程序变更并不是您想听到的。但实际上无法避免,需要一种更智能的方式来存储 blob 才能进行如此大规模的扩展。