十亿文件文件系统

原文 ↗ Hacker News 讨论 ↗

把一个 Linux 文件系统推到能容纳十亿个空文件，会变成对元数据开销、目录索引和工具链限制的压力测试，而不是对原始存储容量的考验。评论者比较了 ext4、XFS、btrfs、ReiserFS、ZFS 和 NTFS 在重度小文件工作负载下的表现，指出了 inode 膨胀、目录操作缓慢和灾难性的删除耗时等问题。很多人认为，对于涉及数百万或数十亿个微小对象的工作负载，数据库或类似 SQLite 的格式、专用文件系统，或者替代布局（例如分片目录或 FUSE/虚拟文件系统）通常比通用文件系统更合适。

这个任务中 Rust 与 shell/Python 的对比

  • 若干评论指出，Rust 程序在概念上很简单（几个 exec 和一个循环），用一小段 shell 脚本就能复现。
  • 也有人认为，当数据集变得很大时（例如数百万个 URL），Rust 的优势会体现在性能、并行性和可维护性上，即使 bash/Python 的快速原型更短。
  • 还有人建议把“mkfs/mount”和 Rust 逻辑拆开，以符合“一件事做好”的原则。

超大目录下的文件系统行为

  • 在 同一个 目录里创建十亿个文件被视为一种独特的压力场景；目录查找和列表显示会成为关键瓶颈。
  • 有人分享了 ls 在 100 万到 1000 万文件上的基准测试；无排序列表（ls -U）和单列输出（-1）都明显快于默认的 ls。
  • ext4 的 htree 索引减轻了内核侧的扩展问题，但那些把整个目录读入内存的用户态工具仍然会表现异常。

空间与元数据开销

  • ext4 的每文件开销（这里一个空文件约 296 字节）主要与 inode 大小（默认 256 字节）以及目录和其他元数据有关。
  • 更小的 inode（例如 128 字节）可以把这一开销减半，但会重新带来 32 位时间戳/Y2038 限制。
  • 一些专门系统（例如 SeaweedFS）宣称每文件元数据开销低得多。

大量小文件的现实经验

  • 有多则轶事：模拟程序生成 10 万个以上小文件、NTFS 目录中数百万文件导致删除或复制都非常缓慢，以及 Linux 系统在每个目录里有数万个文件时表现异常。
  • 其中一个案例描述了 ext4 目录哈希结构在数十亿次文件增删后膨胀到非常大，以至于尽管还有充足空闲空间却出现 ENOSPC，这促使其切换到 XFS。

最佳存储方式：文件系统 vs 数据库 vs 专用文件系统

  • 共识是：通用文件系统并不“擅长”处理海量小文件。
  • 对于许多小对象，数据库（SQLite/Postgres）往往比文件系统表现更好；移动一个数据库文件也远比移动数百万个文件容易。
  • 在合适场景下，也有人建议使用对象存储或只读格式（SquashFS）。
  • ReiserFS 历史上在小文件方面表现出色；Btrfs 和其他系统也有优化，但取舍仍然存在。

替代方案与技巧

  • 有人建议使用一个 FUSE 文件系统，虚拟地暴露十亿个文件，而不是真正创建它们。
  • 大家也分享了各种命令行模式（ls -U1 | wc -l、find ... -printf）以及 getdents() 相关参考，用于更高效地处理大目录。
  • 讨论还涉及 ZFS、Hammer2，以及更广泛的“文件系统 vs 数据库”语义与性能取舍。