在我的职业生涯中，我曾多次在各种环境（例如 CentOS/Debian 机器、Synology/QNAP NAS）中遇到 mdadm RAID 集（RAID1+0、5、6 等），它们似乎根本无法处理故障磁盘。该磁盘并未完全失效，但有数以万计的坏扇区，并且根本无法处理 I/O。但是，它并没有完全死亡，它仍然在工作。内核日志通常充满 UNC 错误。
有时，SMART 会将磁盘识别为故障，有时除了 I/O 缓慢之外没有其他症状。
缓慢的 I/O 实际上会导致整个系统冻结。通过 ssh 连接需要很长时间，webGUI（如果是 NAS）通常会停止工作。通过 ssh 运行命令也需要很长时间。直到我断开/故意将磁盘从阵列中“故障”出来，然后事情就会恢复到“正常” - 这与降级阵列一样正常。
我只是想知道，如果磁盘读取/写入需要很长时间，为什么不将其从阵列中剔除，在日志中添加一条消息并继续？这似乎让整个系统陷入瘫痪，因为一个磁盘有点奇怪，完全抵消了使用 RAID 的主要好处之一（容错 - 在磁盘发生故障时继续运行的能力）。我可以理解，在单磁盘场景中（例如，您的系统连接了单个 SATA 磁盘，并且无法正确执行读/写），这是灾难性的，但在 RAID 集（尤其是容错“个性”）中，它看起来不仅令人讨厌而且违背常识。
mdadm 的默认行为基本上会削弱该盒子，直到有人远程登录并手动修复它，这是否有充分的理由？
Lut*_*lek 14
一般来说，RAID的目的根据所选的 Raid 级别，在数据冗余、可用性、性能和容量等关键目标之间提供不同的平衡。
\n根据具体要求，存储所有者有责任决定各种因素的哪种平衡对于给定目的来说是正确的，以创建可靠的解决方案。
\n所选 Raid 解决方案（在本例中我们讨论的是软件mdadm）的工作首先是确保数据保护。考虑到这一点，很明显，RAID 解决方案的工作并不是将业务连续性置于数据完整性之上。
换句话说：mdadm 的工作是避免失败的 raid。只要“行为怪异的磁盘”没有完全损坏，它仍然有助于袭击。
\n那么，为什么不直接从阵列中剔除一个行为怪异的磁盘，在日志中添加一条消息然后继续呢？因为这样做会增加丢失数据的风险。
\n我的意思是，你是对的，在特定时刻，从商业角度来看，继续下去似乎是更好的解决方案。但实际上，已删除到日志中的消息可能仍然未被检测到，因此 raid 的降级状态仍然未被检测到。一段时间后，最终同一 raid 中的另一个磁盘发生故障，导致故障 raid 上存储的数据最终消失。
\n除此之外：很难准确定义什么是“行为异常的磁盘”。换句话说：在磁盘阵列中操作的单个磁盘的可接受的操作行为是什么？
\n我们中的一些人可能会回答“磁盘显示一些错误”。其他人可能会回答：“只要能改正错误就可以了”。其他人可能会回答：“只要磁盘在给定时间内响应所有命令，就一切正常”。其他人则说“如果磁盘温度与同一阵列中所有磁盘的平均温度相差超过 5\xc2\xb0C”。另一个答案可能是“只要擦洗没有显示错误”，或者“只要 SMART 没有显示错误”。
\n所写的清单并不长，也不是完整的。
\n关键是“磁盘可接受的行为”的定义是一个解释问题，因此也是存储所有者的责任，而不是 mdadm 应该自行决定的事情。
\n关键问题是，发生故障的 SATA 磁盘驱动器有时会在其内部错误恢复过程期间冻结整个总线。因此，应仅在 RAID 阵列（最好是企业级型号）中使用支持 TLER 的驱动器。
SAS 驱动器受此问题影响较小，但也并非完全摆脱此问题。