我最近研究了高级文件系统（Btrfs、ZFS）的数据冗余和可用性，并对它们提供的附加功能感兴趣，尤其是它们针对数据损坏的“自我修复”功能。
但是，我认为我需要退后一步，尝试了解与传统的 mdadm-Raid1 + 相比，对于一般家庭/SMB 使用而言，这种优势是否超过了它们的劣势（Btrfs 错误和未解决的问题以及 ZFS 可用性和性能影响） Ext4 解决方案。无论哪种方式都可以使用镜像备份。
假设我有几个文件服务器用于归档目的并且资源有限，但是 ECC 内存和稳定的电源。
- 我什至遇到实际数据损坏导致文件无法读取的可能性有多大？如何？
- Ext4 或系统文件管理器是否已经检测到复制/移动操作中的数据错误，让我至少意识到一个问题？
- 如果 madam-Raid1 驱动器中的一个驱动器由于一个驱动器有坏扇区而保存了不同的数据，会发生什么情况？我仍然能够检索到正确的文件，还是阵列无法确定哪个文件是正确的并完全丢失？
是的，功能校验和文件系统是一件非常好的事情。然而，真正的动机并不是在神话中的“bitrot”中找到，虽然确实发生了，但非常罕见。相反，主要优点是这样的文件系统提供端到端的数据校验和，通过错误的磁盘行为（例如与磁盘自己的私有 DRAM 缓存失败和/或由于电源导致的异常行为相关的错误写入和数据损坏）来主动保护您问题。
当 Linux RAID 1 阵列由于电源问题而损坏时，我亲身经历了这个问题。一个磁盘的缓存开始损坏数据，并且嵌入在磁盘扇区中的 ECC 本身没有捕获任何东西，这仅仅是因为写入的数据已经损坏，并且 ECC 是根据损坏的数据本身计算的。
多亏了它的校验和日志，它检测到一些奇怪的东西并暂停了文件系统，XFS 限制了损坏；但是，某些文件/目录已不可挽回地损坏。由于这是一台不会立即面临停机压力的备份机器，因此我使用 ZFS 对其进行了重建。当问题再次发生时，在第一次清理期间，ZFS 通过从其他磁盘读取良好副本来纠正受影响的块。结果：没有数据丢失，也没有停机时间。这是使用校验和文件系统的两个很好的理由。
值得注意的是，数据校验和是如此有价值，以至于提供它的设备映射器目标（通过模拟 T-10 DIF/DIX 规范），称为dm-integrity，正是为了将此保护扩展到经典块设备（尤其是冗余块设备）作为 RAID1/5/6)。借助Stratis 项目，它将被集成到一个综合管理 CLI/API 中。
但是，您有一点认为，此类文件系统带来的任何潜在优势都应与它们继承的劣势进行比较。ZFS 的主要问题是它没有被主流化到标准内核中，但除此之外它非常快速和稳定。另一方面，虽然 BTRFS 已成为主流，但存在许多重要问题和性能问题（对数据库或 VM 的常见建议是禁用 CoW，这反过来又禁用了校验和——坦率地说，这不是一个可接受的答案）。与其使用 BTRFS，我会使用 XFS 并希望获得最好的结果，或者使用 dm-integrity 受保护的设备。
我有一个希捷硬盘，每次我运行 zfs scrub 时校验和都会失败。几周后它失败了。ZFS 和 Btrfs 具有数据和元数据的校验和。ext4 只有元数据校验和。
只有 CRC 错误和元数据校验和错误。可能会发生数据损坏。
如果它有坏扇区，那不是问题。整个磁盘将“失败”，但您拥有另一个“正常”的磁盘。问题是数据具有正确的 CRC，但数据已损坏。由于磁盘较大，这可能会随机发生。
我已经在 Linux 和 FreeBSD 下的服务器和家庭办公室 NAS 中使用 ZFS 超过 6 年了。我发现它稳定、快速、可靠，而且我亲眼目睹了它检测和（如果能够）纠正简单
md设备或ext4文件系统无法做到的错误。关于许可，ZFS 是开源的，它只是在 CDDL 许可下发布的，与 Linux 内核发布的 GPLv2 许可在法律上不兼容。详情在这里。这并不意味着它处于“暂时处于等待状态”的状态，也不意味着存在任何技术上的不兼容。它只是意味着主线 linux 内核源代码没有模块，它们必须从https://zfsonlinux.org之类的地方检索。请注意，某些发行版（例如 debian）在其发行版中包含 ZFS 在Debian / Ubuntu 上安装 ZFS 通常可以使用单个
apt命令完成。至于性能，给我足够的 RAM ZFS 性能从接近 ext4 到超过 ext4，取决于内存、可用池空间和数据的可压缩性。在我看来，ZFS 的最大缺点是内存使用：如果生产服务器的 RAM 少于 16 GiB，则可能需要避免使用 ZFS。这是一个过于简单的经验法则。网上有很多关于 ZFS 内存要求的信息。我个人在具有 32GB RAM 的家庭办公室 Linux 系统上运行了一个 10TB 池和一个 800GB 池以及一些备份池，性能非常好。该服务器还运行 LXC 并运行多个服务。
ZFS 功能远远超出了数据校验和和自我修复功能；它强大的快照比 LVM 快照要好得多，而且它的内联 lz4 压缩实际上可以通过减少磁盘写入来提高性能。我个人在 10TB 池上节省了 1.55 倍（在磁盘上仅 6.3GiB 的空间中存储 9.76GiB 的数据）
根据我的经验，当池达到 75% 或 80% 的使用率时，ZFS 性能会下降。只要您保持在该点以下，性能对于一般家庭/SMB 使用来说应该绰绰有余。
在我看到 ZFS 检测并纠正不良数据的情况下，根本原因尚不清楚，但很可能是坏磁盘块。我也有 ECC 内存并使用 UPS，所以我不相信 RAM 中的数据已损坏。事实上，您需要 ECC RAM 才能从 ZFS 校验和中获益。然而，在过去的 6 年里，我看到了少数（~10-15）个校验和失败的块案例。ZFS 相对于 md RAID 的一个主要优势是 ZFS 知道哪些文件会受到校验和错误的影响。因此，如果没有冗余的备份池出现校验和错误，ZFS 会告诉我受影响的确切文件，允许我替换这些文件。
尽管 ZFS 使用的许可证与 linux 内核不兼容，但安装模块非常容易（至少在 Debian 上），并且一旦熟悉了工具集，管理就很简单。尽管许多人表示担心 Internet 上的 ZFS 会导致全部数据丢失，但自从迁移到 ZFS 以来，我从未丢失过任何数据，而且 ZFS 快照和数据校验和/冗余的组合使我个人免于遭受多次数据丢失的困扰。这是一个明显的胜利，我个人永远不会回到
md阵列。如果有足够的时间，它几乎肯定会发生。巧合的是，上周发生在我身上。我的家庭文件服务器开发了一些导致定期锁定的坏 RAM。最终我决定简单地淘汰这台机器（它已经相当老了）并将驱动器移动到另一台机器上的机箱中。导入后清理从 8TB 池中发现并修复了 15 个存在校验和错误的块，这可能是由坏 RAM 和/或锁定引起的。磁盘本身具有来自 SMART 的干净健康证明，并且在随后的擦洗中测试良好。
不，不是。某些文件格式中可能存在应用程序级校验和，但除此之外，没有什么可以留意我的案例中发生的那种损坏。
如果您明确知道一个驱动器坏了，您可以将该驱动器从阵列中取出并提供来自好驱动器的所有读取（或者，更明智的是，更换坏驱动器，这会将数据从好驱动器复制到替换驱动器上）。但是，如果驱动器上的数据由于写入时的随机位翻转（发生在我和 shodanshok 身上的那种事情）而不同，则没有明确的方法可以在没有校验和的情况下选择两者中的哪一个是正确的。
此外，md 通常不会注意到镜像中的两个驱动器在正常操作期间不同步 - 它会以任何方式将读取定向到一个磁盘或另一个磁盘以获得最快的结果。有一个“检查”功能可以读取镜像对的两侧并报告不匹配，但前提是您运行它，或者您的发行版设置为定期运行它并报告结果。
我可以补充一点，ZFS 非常健壮，这主要归功于它的起源（它是由 Sun Microsystems 早在 2001 年开发的）。目前可用的开源版本是 Sun Microsystems 大约 10 年前发布的最后一个开源版本之一的一个分支，在 Oracle 在收购 Sun Microsystems 后关闭 ZFS 源后，开源社区进一步开发了该版本。
Oracle 自己还维护着一个封闭源代码版本的 ZFS，用于他们的企业存储系统。
不过 ZFS 有一点学习曲线，因为它非常强大，有很多东西可以调整。它也是我从事过的为数不多的易于维护的存储文件系统之一。我有一种情况，需要将池从 RAID5 设置迁移到 RAID6（或者更准确地说是从 RAID-Z1 迁移到 RAID-Z2）。通常，这样的操作意味着复制所有数据，重新配置 RAID，然后将数据复制回。在 ZFS 中，您附加辅助存储，并使用一个命令复制池，根据需要重新配置阵列，然后使用另一个命令将池复制回来。
不过有一些陷阱：
对于初学者和家庭环境，我一般推荐 FreeNAS，它维护得很好并且设置简单，这对初学者来说非常有用。
显然，给定无限的时间，你肯定会遇到它。
但实际上，除非您拥有非常昂贵的企业级硬件，否则它仍然很有可能，即使那样也不是不太可能。
但更有可能的是，您最终会遇到数据损坏，它只会更改文件内容，但不会使它们不可读（除非您有大量的小文件，简单的统计数据意味着您更有可能在文件数据而不是文件元数据）。发生这种情况时，您可能会遇到各种奇怪的行为，就像您有坏硬件一样（尽管通常它会比坏硬件更加一致和本地化）。如果幸运的话，会损坏一些非关键数据，并且您可以轻松找到一些东西。如果你运气不太好，你必须从头开始重建系统。如果你真的不幸的是，您刚刚遇到了一个导致您破产的错误，因为它碰巧触及了生产系统中的关键数据，并且您的服务现在停止了，而您从头开始重建整个事物并尝试将数据库恢复到应有的方式是。
简短的回答是，数据损坏可能足以让家庭用户也担心它。
Ext4 在这一点上是出了名的糟糕。遇到内部一致性错误时，它们的默认行为是将文件系统标记为在下次重新挂载时进行检查，然后继续进行，就好像没有任何问题一样。由于这种行为，我过去失去了整个系统。
更一般地说，在大多数情况下，如果文件系统本身的数据结构或文件元数据遇到内部错误，那么您可以从并非专门设计用于验证其数据的文件系统中获得的最大希望是重新以只读方式挂载。问题是，除非文件系统专门处理它自己的内部结构的验证，而不是像边界检查这样简单的东西，否则这不会捕获所有东西，事情只会以奇怪的方式出错。
要获得更多信息，您需要文件系统使用校验和、纠错码、擦除编码或其他类似方法来验证它自己的内部数据结构。即使那样，除非它对文件数据做同样的事情，否则您仍然面临不可忽视的数据丢失风险。
这取决于 RAID 级别、确切的 RAID 实施以及您是否将其设置为自动恢复。假设您有自动恢复：
对于 RAID1 和 RAID10：
对于 RAID4/5/6 和其他纠删码情况，在恢复时几乎所有行为都相同，要么从剩余设备重建数据（如果可以），要么阵列实际上丢失了。在这种情况下，ZFS 和 BTRFS 只是为您提供了一种更快（就总 I/O 而言）检查数据是否正确的方法。
请注意，这些都不是在每个文件的基础上运行的，并且大多数都不允许您轻松选择“正确”的，它们要么完全工作，要么完全失败，或者交替返回不同步区域的好数据或坏数据。
为了完整起见，我想提一下https://bcachefs.org，诚然它还没有在内核中，但恕我直言，一旦它出现，它将取代 ZFS 和 btrfs。
它基于已经在内核中存在很长时间的 bcache，利用其 B-tree 系统构建文件系统功能。
孤独的开发人员全职工作，由 Patreon 赞助，并且非常注重可靠性。
目前不适合胆小的人，但随着这个评论的老化，bcachefs 应该会改进:)