使用 mdadm 进行位腐烂检测和纠正

Question

我即将在我的家用 linux 机器 nas 中重新组织我的所有 HDD，并希望使用 mdadm raid 进行数据保护及其重新调整阵列的灵活性。但是，在为此使用 mdadm 之前，我想知道它是如何处理bit rot 的。特别是不会导致从 HDD 发送的不可恢复的读取错误消息的位腐烂类型。

由于我很可能会使用硬盘驱动器的至少21TB在NAS 8个磁盘，并在各种行情概率的故障HDD上，我在想，期间从单个磁盘故障重建我非常有可能遭遇剩余磁盘上的某种形式的位腐烂。如果其中一个驱动器出现不可恢复的读取错误，驱动器实际上将其报告为错误，我相信raid6 应该没问题（是吗？）。但是，如果从磁盘读取的数据是错误的但磁盘没有报告，那么即使使用raid6，我也看不到如何自动更正。这是我们需要关心的事情吗？鉴于文章It is 2010 and RAID5 仍然有效，以及我自己在家庭和工作中的成功经验，事情并不一定像流行语和营销让我们相信的那样悲观和悲观，但我讨厌仅仅因为硬盘故障而不得不从备份中恢复。

鉴于使用模式将是，最多写入几次，偶尔读取，我需要执行数据清理。我在archlinux wiki上看到 用于数据清理数组的 mdadm 命令为

echo check > /sys/block/md0/md/sync_action

然后监控进度

cat /proc/mdstat

在我看来，它会读取所有磁盘的所有扇区并检查数据是否与奇偶校验匹配，反之亦然。尽管我注意到文档中非常强调在某些重要情况下“检查”操作将无法自动更正，只能检测，并且将由用户来修复。

我应该选择什么 mdadm RAID 级别来最大限度地防止位腐烂，我应该做哪些维护和其他保护步骤？这不能保护我免受什么伤害？

编辑：我不打算开始 RAID vs ZFS 或任何其他技术 QA。我想特别了解 mdadm raid。这也是为什么我在 Unix & Linux 而不是SuperUser上询问的原因。

编辑：答案是： mdadm 只能更正数据清理期间磁盘系统报告的 URE，并在清理期间检测静默位腐烂但不能/不会修复它？

Answer 1

我没有足够的代表来发表评论，但我想指出 Linux 中的 mdadm 系统不会纠正任何错误。如果您告诉它在清理（例如 RAID6）期间“修复”错误，如果存在不一致，它将通过假设数据部分正确并重新计算奇偶校验来“修复”它。

Answer 2

坦率地说，我觉得您拒绝 RAIDZ2 ZFS 相当令人惊讶。它似乎几乎完美地满足了您的需求，除了它不是 Linux MD。我并不是要为大众带来 ZFS，但简单的事实是，您的问题是 ZFS从头开始设计要解决的问题之一。依靠 RAID（任何“常规”RAID）在减少或没有冗余的情况下提供错误检测和纠正似乎有风险。即使在 ZFS 无法正确纠正数据错误的情况下，它至少可以检测到错误并让您知道存在问题，从而允许您采取纠正措施。

你不具备做定期的全磨砂与ZFS，虽然它是推荐的做法。ZFS 将验证从磁盘读取的数据是否与读取数据时写入的数据匹配，并且在不匹配的情况下 (a) 使用冗余来重建原始数据，或 (b) 将 I/O 错误报告给应用程序。此外，清理是一种低优先级的在线操作，与大多数文件系统中的文件系统检查完全不同，后者既可以是高优先级，也可以是离线操作。如果您正在运行擦洗并且擦洗以外的其他东西想要执行 I/O，则擦洗将在此期间处于次要位置。ZFS 清理取代了 RAID 清理和文件系统元数据和数据 完整性检查，因此比只是擦洗 RAID 阵列以检测任何位腐烂要彻底得多（这不会告诉您数据是否有意义，仅表明 RAID 控制器已正确写入数据）。

ZFS 冗余（RAIDZ、镜像等）的优点是无需在清理期间检查未使用的磁盘位置的一致性；在清理期间只检查实际数据，因为这些工具会遍历分配块链。这与非冗余池相同。对于“常规”RAID，必须检查所有数据（包括磁盘上任何未使用的位置），因为 RAID 控制器（无论是硬件还是软件）不知道哪些数据实际上是相关的。

通过使用 RAIDZ2 vdevs，任何两个组成驱动器都可以在您面临另一个驱动器故障导致实际数据丢失的风险之前发生故障，因为您有两个驱动器的冗余。这与 RAID6 基本相同。

在 ZFS 中，所有数据，包括用户数据和元数据，都经过校验和（除非您选择不这样做，但建议不要这样做），并且这些校验和用于确认数据没有因任何原因发生更改。同样，如果校验和与预期值不匹配，数据将被透明地重建或报告 I/O 错误。如果报告了 I/O 错误，或者清理识别出损坏的文件，您将知道该文件中的数据可能已损坏，并且可以从备份中恢复该特定文件；无需完整阵列还原。

普通的，即使是双奇偶校验，RAID 也不能保护您免受诸如一个驱动器故障和另一个驱动器错误地从磁盘读取数据的情况。假设一个驱动器发生故障，并且任何其他驱动器的任何位置都发生了一个位翻转：突然间，您发现了未检测到的损坏，除非您对此感到满意，否则您至少需要一种方法来检测它。减轻这种风险的方法是对磁盘上的每个块进行校验和，并确保校验和不会与数据一起损坏（防止诸如高速写入、孤立写入、写入磁盘上不正确位置等错误），这只要启用校验和，这正是 ZFS 所做的。

唯一真正的缺点是您无法通过向其添加设备来轻松扩展 RAIDZ vdev。有一些解决方法，通常涉及像稀疏文件作为 vdev 中的设备之类的东西，并且经常被称为“如果这是我的数据，我就不会这样做”。因此，如果您采用 RAIDZ 路线（无论您采用 RAIDZ、RAIDZ2 还是 RAIDZ3），您都需要预先决定每个 vdev 中需要多少个驱动器。尽管 vdev 中的驱动器数量是固定的，但您可以通过逐渐（确保保持在 vdev 的冗余阈值内）用更大容量的驱动器替换驱动器并允许完全重新同步来增加 vdev。

Answer 3

这个答案是根据我发现的各种证据进行推理的产物。我不知道 Linux 内核实现是如何工作的，因为我不是内核开发人员，而且似乎存在大量无意义的错误信息。我认为 Linux 内核做出了明智的选择。除非我弄错了，否则我的答案应该适用。

\n\n

许多驱动器使用 ECC（纠错码）来检测读取错误。如果数据损坏，内核应从支持 ECC 的驱动器接收该块的 URE（不可恢复的读取错误）。在这些情况下（下面有一个例外），将损坏的或空的数据复制到良好的数据上将等同于疯狂。在这种情况下，内核应该知道哪些数据是好数据，哪些数据是坏数据。根据It is 2010 and RAID5 still Works \xe2\x80\xa6文章：

\n\n

\n

考虑一下这个替代方案，我知道至少有几个阵列供应商正在使用它。当 RAID 卷中的驱动器报告 URE 时，阵列控制器会增加计数并通过奇偶校验重建块来满足 I/O。然后，它在报告 URE 的磁盘上执行重写（可能带有验证），如果扇区损坏，微代码将重新映射，一切都会好起来的。

\n

\n\n

然而，现在有一个例外：如果驱动器不支持 ECC、驱动器谎称数据损坏或固件功能异常，则可能不会报告 URE，并且会将损坏的数据提供给内核。在数据不匹配的情况下：似乎如果您使用的是2个磁盘的RAID1或RAID5，那么即使处于非降级状态，内核也无法知道哪个数据是正确的，因为只有一个奇偶校验块并且没有报告 URE。在 3 磁盘 RAID1 或 RAID6 中，单个损坏的非 URE 标记块将与冗余奇偶校验（与其他关联块组合）不匹配，因此应该可以进行正确的自动恢复。

\n\n

这个故事的寓意是：使用带有 ECC 的驱动器。不幸的是，并非所有支持 ECC 的驱动器都会宣传此功能。另一方面，要小心：我知道有人在 2 磁盘 RAID1（或 2 副本 RAID10）中使用廉价 SSD。其中一个驱动器在每次读取特定扇区时都会返回随机损坏的数据。损坏的数据会自动复制到正确的数据上。如果 SSD 使用 ECC，并且运行正常，那么内核应该采取适当的纠正措施。

\n