我即将重新组织我的家用 Linux NAS 中的所有 HDD，并希望使用 mdadm raid 进行数据保护及其重塑阵列的灵活性。但是，在我使用 mdadm 之前，我想知道它是如何处理的位腐烂。具体来说，不会导致从 HDD 发送不可恢复的读取错误消息的位衰减类型。
考虑到我可能会在 nas 的 8 个磁盘中使用至少 21TB 的 HDD 以及各种报价概率的失败在 HDD 上，我认为在从单个磁盘故障进行重建的过程中，我很可能会在其余磁盘上遇到某种形式的位损坏。如果其中 1 个驱动器上出现不可恢复的读取错误，并且该驱动器实际上将其报告为错误，我相信 raid6 应该没问题（是吗？）。但是，如果从磁盘读取的数据是坏的，但磁盘没有这样报告，那么即使使用 raid6，我也看不到如何自动纠正此问题。这是我们需要关心的事情吗？鉴于文章现在是 2010 年了，RAID5 仍然有效以及我自己在家庭和工作中的成功经验，事情并不一定像流行语和营销让我们相信的那样厄运和沮丧，但我讨厌仅仅因为硬盘出现故障就必须从备份中恢复。
鉴于使用模式是，最多写入几次，偶尔读取，我需要执行数据清理。我看到 archlinux 维基 mdadm 命令数据清理一个数组作为
echo check > /sys/block/md0/md/sync_action
然后监控进度
cat /proc/mdstat
在我看来，它将读取所有磁盘的所有扇区并检查数据是否与奇偶校验匹配，反之亦然。尽管我注意到文档中非常强调，在某些重要情况下，“检查”操作将无法自动更正，只能检测，并且将由用户自行修复。
我应该选择什么 mdadm RAID 级别来最大限度地防止位损坏，以及我应该执行哪些维护和其他保护步骤？这不能保护我免受什么伤害吗？
编辑：我不想启动 RAID 与 ZFS 或任何其他技术 QA。我想具体了解 mdadm raid。这也是为什么我要问 Unix & Linux 而不是超级用户。
编辑：答案是：mdadm 只能更正数据清理期间磁盘系统报告的 URE 并在清理期间检测静默位腐烂，但不能/不会修复它？
答案1
我没有足够的代表来发表评论，但我想指出 Linux 中的 mdadm 系统不会纠正任何错误。如果您告诉它在清理（例如 RAID6）期间“修复”错误，如果存在不一致，它将通过假设数据部分正确并重新计算奇偶校验来“修复”它。
答案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 vdev，任何两个组成驱动器都可能发生故障，然后您才会面临因另一个驱动器故障而导致实际数据丢失的风险，因为您拥有两个驱动器的冗余。这本质上与 RAID6 相同。
在 ZFS 中，所有数据（用户数据和元数据）都会进行校验和（除非您选择不这样做，但建议不要这样做），并且这些校验和用于确认数据未因任何原因发生更改。同样，如果校验和与预期值不匹配，则数据将被透明地重建或将报告 I/O 错误。如果报告 I/O 错误，或者清理识别出损坏的文件，您将知道该文件中的数据可能已损坏，并且可以从备份中恢复该特定文件；无需完整阵列恢复。
普通的 RAID 甚至双奇偶校验也无法保护您免受诸如一个驱动器发生故障而另一个驱动器错误地从磁盘读取数据等情况的影响。假设一个驱动器发生故障，并且其他驱动器中的任何一个驱动器都发生了单个位翻转：突然间，您遇到了未被发现的损坏，除非您对此感到满意，否则您至少需要一种方法来检测它。减轻这种风险的方法是检查磁盘上每个块的校验和，并确保校验和不会与数据一起损坏（防止出现诸如高飞写入、孤立写入、写入磁盘上的错误位置等错误），这正是 ZFS 在启用校验和的情况下所做的。
唯一真正的缺点是您无法通过向其中添加设备来轻松扩展 RAIDZ vdev。有一些解决方法，通常涉及将稀疏文件作为 vdev 中的设备，通常被称为“如果这是我的数据，我就不会这样做”。因此，如果您选择 RAIDZ 路线（无论您选择 RAIDZ、RAIDZ2 还是 RAIDZ3），您需要预先决定每个 vdev 中需要多少个驱动器。尽管 vdev 中的驱动器数量是固定的，但您能通过逐渐（确保保持在 vdev 的冗余阈值内）用更大容量的驱动器替换驱动器并允许完全重新同步来增加 vdev。
答案3
这个答案是根据我发现的各种证据进行推理的产物。我不知道 Linux 内核实现是如何工作的，因为我不是内核开发人员，而且似乎存在大量无意义的错误信息。我认为 Linux 内核做出了明智的选择。除非我弄错了，否则我的答案应该适用。
许多驱动器使用 ECC（纠错码）来检测读取错误。如果数据损坏，内核应从支持 ECC 的驱动器接收该块的 URE（不可恢复的读取错误）。在这些情况下（下面有一个例外），将损坏的或空的数据复制到良好的数据上将等同于疯狂。在这种情况下，内核应该知道哪些数据是好数据，哪些数据是坏数据。根据现在是 2010 年了，RAID5 仍然有效……文章：
考虑一下这个替代方案，我知道至少有几个阵列供应商正在使用它。当 RAID 卷中的驱动器报告 URE 时，阵列控制器会增加计数并通过奇偶校验重建块来满足 I/O。然后，它在报告 URE 的磁盘上执行重写（可能带有验证），如果扇区损坏，微代码将重新映射，一切都会好起来的。
然而，现在有一个例外：如果驱动器不支持 ECC、驱动器谎称数据损坏或固件功能异常，则可能不会报告 URE，并且会将损坏的数据提供给内核。在数据不匹配的情况下：似乎如果您使用的是2磁盘RAID1或RAID5，那么即使处于非降级状态，内核也无法知道哪些数据是正确的，因为只有一个奇偶校验块，并且没有报告 URE。在 3 磁盘 RAID1 或 RAID6 中，单个损坏的非 URE 标记块将与冗余奇偶校验（与其他关联块组合）不匹配，因此应该可以进行正确的自动恢复。
这个故事的寓意是：使用带有 ECC 的驱动器。不幸的是，并非所有支持 ECC 的驱动器都会宣传此功能。另一方面，要小心：我知道有人在 2 磁盘 RAID1（或 2 副本 RAID10）中使用廉价 SSD。其中一个驱动器在每次读取特定扇区时都会返回随机损坏的数据。损坏的数据会自动复制到正确的数据上。如果 SSD 使用 ECC，并且运行正常，那么内核应该采取适当的纠正措施。
答案4
为了获得您想要的保护，我会选择 RAID6 + 2 个位置的正常异地备份。
无论如何，我个人每周清理一次，并根据数据重要性和更改速度每晚、每周和每月进行备份。