在我的职业生涯中，我曾多次在各种环境（例如 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 的默认行为基本上会削弱该盒子，直到有人远程登录并手动修复它，这是否有充分的理由？
在任何人回答“询问您的 ISP”或“询问您的托管提供商”之前，请完整阅读。
设想：
mydomain.example和一个公共路由的 IP 块（比如说192.0.2.0/28）ns1.mydomain.example并ns2.mydomain.example指向我的服务器（自托管 DNS 服务器）问题：我将我的域 ( mydomain.example) 的 DNS 托管从我自己的服务器迁移到 cloudflare，认为不值得麻烦地 DIY 托管它。我之前曾多次使用相同的设置执行此操作，并且没有遇到任何不良影响。
然而，当 NS 记录更新到 cloudflare 时，我发现我的反向 DNS 完全停止工作了。
问题：什么/谁决定谁回答我的 IP 块的反向 DNS 查询？据我了解，通常情况下，正向 DNS 和反向 DNS 是彼此独立完成的，因此我并不期望正向查找名称服务器从自托管基础设施 -> cloudflare 迁移到火炬反向 DNS 查找。
据我了解，应答您的正向 dns (cloudflare) 的实体独立于应答您的反向 DNS 的实体（例如您的托管提供商、ISP 等）。但是，我如何确认谁真正对此负责- 就像我对我的转发 DNS 负责一样？我可以% dig +short mydomain.example NS确认哪些服务器负责正向 …