MinIO，云存储的ZFS

ZFS 最出名的是通过将物理存储设备边界池化在一起来进行抽象。ZFS 完全消除了手动处理物理存储或担心其个别容量的需要。ZFS 也是数据损坏检测和在可用数据冗余的情况下恢复数据能力的先驱。

然而，正如我们之前讨论的，传统的 文件系统无法处理现代应用程序的需求。应用程序现在需要能够以编程方式处理非结构化数据的方法，同时对数据丢失或安全漏洞的容忍度非常低。

显然，使用当前的文件系统很难实现这一点。但是，如果 ZFS 演变为云存储系统会怎样？它会是什么样子？我非常确定它会类似于当今的 MinIO。是什么让我这么说？嗯，有很多原因。我将在本文中介绍所有这些原因。

防止静默数据损坏，也称为比特腐烂

静默数据损坏或比特腐烂是磁盘驱动器面临的一个严重问题，其中存储在其中的数据可能会在用户甚至不知道的情况下损坏。这可能是由于多种因素造成的（但不仅限于此），例如电流尖峰、磁盘固件中的错误、幻影写入、错误的读/写操作、阵列和服务器内存之间的 DMA 奇偶校验错误、驱动程序错误以及意外覆盖。

ZFS 可能是第一个提供针对这些数据损坏问题保护的开源文件系统。ZFS 使用基于 Fletcher 的校验和或SHA-256哈希遍布整个文件系统树，每个数据块都进行校验和计算，并将值保存在指向该块的指针中——而不是在实际的块本身中。这种校验和计算一直持续到文件系统的数据层次结构的根节点。

现在，由于 ZFS 将每个块的校验和存储在其父块指针中，因此当访问块时，整个池会进行自我验证，无论它是数据还是元数据。当计算校验和并将其与存储的“应该是什么”的校验和值进行比较时，就会发生验证。

同样，MinIO 提供了全面的数据损坏和比特腐烂问题的保护，尽管使用了更快的哈希算法和基于擦除编码的广泛数据恢复机制。

为了防止比特腐烂，MinIO 通过计算从磁盘读回的数据块的哈希值并将其与最初计算的哈希值（在存储数据时）进行比较，来验证数据块的完整性。只有当两个哈希值相同的时候，才能保证数据没有以任何方式被更改。如果哈希值之间有任何差异，则该块本身将被丢弃，并且必须从其他数据和奇偶校验块中重建。稍后我们将回到重建，让我们首先了解 MinIO 中的哈希。

哈希

MinIO 使用 Highway 哈希算法的优化实现——highwayhash，完全用 Go 编写。它可以在英特尔 CPU 的单个核心上实现超过10 GB/秒的哈希速度。

您可以想象，哈希必须在几乎每次数据读取（进行验证）和数据写入（保存初始哈希）时运行，因此哈希速度快且准确非常重要。这就是为什么我们投入时间和精力到highwayhash，它非常适合此类用例。您可以在此博文中阅读更多相关信息。

擦除码

擦除码是一种纠错码，它将k个符号的消息转换为具有n个符号的更长的消息（码字），以便可以从n个符号的子集中恢复原始消息。

MinIO 使用Reed-Solomon码将对象划分为 n/2 个数据块和 n/2 个奇偶校验块。这意味着在 12 个驱动器的设置中，一个对象被分片到 6 个数据块和 6 个奇偶校验块中。即使您丢失了多达 5 个（(n/2)–1）驱动器，无论是奇偶校验还是数据，您仍然可以从剩余的驱动器中可靠地重建数据。

这与 RAID 相比如何？

与 RAID 或复制不同，擦除码可以保护数据免受多个驱动器故障的影响。例如，RAID 6 可以防止 2 个驱动器故障，而使用 MinIO 擦除码，您可以丢失多达一半的驱动器，仍然可以恢复您的数据。

此外，MinIO 的擦除码是在对象级别，因为每个对象都单独使用高奇偶校验计数进行编码。因此，它可以一次修复一个对象。而对于 RAID，修复只能在卷级别执行，这会导致巨大的停机时间。

此外，MinIO 的基于擦除码的后端设计用于操作效率，并在可用时充分利用硬件加速。

可扩展性

ZFS 的另一个关键方面是能够根据您的需求进行扩展。从软件角度考虑，ZFS 理论上可以扩展到泽字节级的存储。另一方面，MinIO 以多租户方式扩展，其中每个租户的数据都存储在单独的 MinIO 实例上。这将扩展与软件的物理限制解耦。无论您拥有数百、数千还是数百万个租户——只要每个租户都有一个单独的 MinIO 实例提供服务，部署就非常简单，并且可以轻松扩展。

这种设置不仅可以轻松维护（在任何给定时间只有少数租户出现故障），还可以使部署保持简单，并易于扩展和缩减。

但是，如果您更喜欢大型部署，MinIO 最近引入了大型桶支持，使您能够从一开始就启动 PB 级别的部署。阅读更多信息。

在您使用 MinIO 的过程中，请帮助我们了解您的用例以及我们如何更好地帮助您！填写我们的 MinIO 最佳部署表单（不到一分钟），并有机会在 MinIO 网站上展示您的 MinIO 私有云设计，并向 MinIO 社区展示。