什么是管理数百万图像的最佳文件系统？

Question

我正在设计一个能够处理 1500 万个（且数量还在增长）图像文件的系统，文件大小从 100k 到 10mb 不等。我正在寻找一些关于哪种文件系统可能是支持（有点）奇怪的要求的最佳文件系统的意见：

附加信息/要求：

• 目录结构肯定是非可选的[1]，但是由于提取这些数据的应用程序的设计，它相对不可变。
• 数据应该进行读取优化，包括但不限于：随机读取、顺序读取、目录列表（某些目录可能有 30,000 个目录或 1,000 个图像）等。
• 额外的数据将定期写入文件结构（新子目录、现有子目录中的附加文件等），但写入性能并不是一个大问题。数据将通过 SMB 或 NFS 写入。
• 有大量相同的文件（保守估计为 20%），但由于提取这些数据的应用程序的设计，我们无法删除重复的文件名。理想情况下，我们希望进行某种重复数据删除（我们当然可以进行硬链接，但我不确定数百万个硬链接的规模如何）
• SSD 将是该项目的主要存储形式（除非可以使用旋转器代替），因此我们希望尽可能限制对系统的写入。

我们为这个项目分配的硬件如下：

Dell R720xd w/ 24x 2.5” bays
RAM: 128GB RAM (more can be allocated if needed)
CPU: 2x E5-2620 @ 2.20GHz
Storage:
    8x2TB SSDs local storage
    1x500GB SSD for OS
RAID: H310 (IT Mode)

我们最初考虑使用 ZFS 来实现这一点，但经过一些额外的研究后发现：

• 在写入元数据更新时，ZFS 可能会破坏 SSD。
• ZFS 的重复数据删除对 RAM 的要求很高（每 1TB 数据需要 5GB RAM）。虽然这在我们当前的硬件上应该是可行的，但似乎开销很大。
• RiserFS 可能更适合对小文件进行随机查找（我似乎找不到什么是“小”文件）。

如果您对这种用例的最佳文件系统以及任何硬件调整有任何意见，我们将不胜感激。

[1]

示例目录结构（所有目录或文件名均未以任何方式进行规范化（顺序等））

+ root directory 1
    - sub directory 1
        - image 1
        - image 2
        - image 3
        - ...
        - image n (where n is between 1 and 1,000+)
    - sub directory 2
        - image 1
        - image 2
        - image 3
        - ...
        - image n
    ....
    - sub directory n (where n is between 1,000 and 30,000)
        - image 1
        - image 2
        - image 3
        - ...
        - image n
+ root directory 2
+ ...
+ root directory 15

Answer 1

任何文件系统（包括低端的 ext4 和稍低端的 XFS）都可以满足您列出的要求，这些要求基本上是能够存储大量文件并在各种用例中具有合理的性能。我的知识（以及此答案中有趣的权衡）主要与 ZFS 有关，因此我将重点介绍它。

您可以从 ZFS 获得的额外功能包括：

1. 重复数据删除。正如您所说，这在 ZFS 中并不是特别好，因为它对 RAM 的要求很高，但它确实有效。要在非 ZFS 上获得类似的效果，您可以对文件进行哈希处理，并使用哈希作为文件名/目录名，或者保留一个哈希 -> 文件名的数据库，以便您可以创建硬链接。（在任何一种情况下，您都需要确切地相同的文件，而不仅仅是看起来相同的图像)。
2. 压缩。大多数图像已经压缩，因此压缩可能帮不了你什么忙，但如果它们是 RAW 格式而不是 JPEG 格式，压缩可以帮你省下不少钱。如果不是，压缩可能帮不了你什么忙。
3. 快照/备份能力。ZFS 有出色的内置工具。您也可以备份非 ZFS，尽管获取数据的一致快照可能很困难。LVM 可以完成部分工作，尽管可能做得不是很好。
4. 卷管理是 ZFS 的一部分。您可以从一组非常灵活的 RAID 配置中进行选择，以获得适合您特定应用程序的 [数据冗余、空间使用、性能] 的最佳配置。您可以从 LVM 和其他软件 RAID 中获得其中的一些，但我相信 ZFS 拥有目前设计最好的卷管理解决方案之一，并结合了精心设计的故障检测和恢复系统。

您提到的另外两件事：

• 元数据混乱。我不认为 ZFS 会比其他文件系统更糟糕：它确实会在写入期间更新大量元数据，但它是写时复制，并且每 5-10 秒批量进行这些更新，这意味着正在发生大块连续写入，而不是需要多次擦除和重写 NAND 块的小块就地写入。在传统文件系统中，您最终会采用另一种方式，因为它将进行就地更新，这可能稍微糟糕一些。无论如何，现代 SSD 内部有很多额外的块，它们保留这些块以在出现磨损的情况下延长驱动器的使用寿命——正常的驱动器寿命被认为与磁盘寿命相当。我不是说这不重要，我只是认为你不应该太关注这个方面，因为它很小。
• 硬链接可扩展性。应具有与普通文件一样好的或更好的扩展性（无论是否在 ZFS 中）。无论哪种方式，硬链接只是指向与其他文件相同的 inode 的指针，并且您可能只会获得非常小的缓存效率提升，因为从其中一个链接读取该文件也会使其缓存以供通过其他链接访问。