当我将 RAID 设置中的硬盘上的某个扇区标记为“有缺陷（GLIST）”时会发生什么？
数据会立即写入替换扇区吗？还是取决于实际设置（软/硬件 raid）？
示例：Raid 5 - 4 个驱动器 - Linux 硬件 Raid
在 HDD 1 上，扇区 0x123456 损坏。它被标记为有缺陷。这导致该扇区上的数据被标记为丢失，并且该扇区现在将指向供应商特定的数据。但由于 raid 包含 1 个副本，因此可以恢复有效数据。
什么时候才能恢复损坏的驱动器上的数据，从而再次拥有两组有效数据？
我想象它是以下之一：
- 读取时修复（下次读取数据时将数据写入替换扇区）
- 标志修复（在扇区被标记为有缺陷后，立即将数据写入替换扇区）
- 必须手动触发修复（命令触发重建）
如果它确实是一个单独的问题/设置，那么我会对 Smart Array P800 特别感兴趣。
但请随时分享您对此所了解的任何信息。
PS：如果你通过谷歌找到了这个，那么smartmontools网站是一个很好的起点：例如http://smartmontools.sourceforge.net/badblockhowto.html#bb
答案1
依靠。
在日常业务中，您的硬盘确实会为每个正在写入的扇区写入校验和和一些 ECC 信息，并在读取操作期间验证这些数据。
如果错误很小（例如翻转位或其他小错误），可以被硬盘的 ECC 功能覆盖，则硬盘可能会自行恢复。更正后的错误可能仍可在 SMART 输出中看到，但操作系统或硬件 RAID 控制器未注意到读取错误。
否则，硬盘将向您的控制器报告不可恢复的读取错误，并在内部将该扇区标记为已损坏。尝试将数据写入同一（逻辑）扇区可让您的硬盘从保留扇区列表中分配替换扇区，并透明地将访问从逻辑扇区映射到新的（替换）物理扇区。您的写入请求将存储在不同的物理扇区上，从而为您修复错误。
如果磁盘没有替换扇区，这也会失败，并且您无法再通过重写相同的逻辑扇区来恢复。
硬件 raid 控制器通常会尝试通过执行后台媒体扫描、计划的自检和验证存储的 raid 奇偶校验的准确性来“更早”地发现此类故障扇区。
如果通过重写同一扇区来修复错误则是另一回事，该领域基本上没有记录，主要取决于个人经验。仅从我 15 年来在数万台服务器上运行来自六家不同供应商的数十个硬件 raid 控制器的经验来看：
- 有些供应商总是会执行后台介质扫描，并默默地尝试自动修复坏块。HP/Compaq 就是这么做的。
- 一些供应商将永久后台媒体扫描作为选项，必须专门打开（开机后默认为“关闭”）。
- 一些供应商提供一次性的后台媒体扫描功能，该功能需要通过管理界面或 CLI 手动触发
- 一些供应商的利润甚至更高。
举个“进一步突破”的例子，大约 10 年前，我在特定控制器类型的 RAID 10 配置中遇到了严重问题：有时，文件系统和应用程序数据会损坏。进一步调查并在应用程序级别引入校验和显示，有时会读取零，但预期的是非零数据。
罪魁祸首：从坏块读取时，控制器将其记录为错误，但根本没有从工作副本中恢复。相反，它报告周围的 8k 数据条带为零条带，读取操作成功。该行为在 100 多个控制器上可重现，供应商的客户支持甚至表示这是完全可以接受的，因为 RAID 只能从整个磁盘故障中恢复，而不处理单个块的故障。
在 RAID4/RAID5 配置中，相同的控制器将从 RAID 冗余中恢复并将恢复的条带传送到操作系统，但不会自动恢复磁盘上的坏块。为了从坏块中恢复，必须在操作系统级别重写相同的逻辑块，或者在管理界面中发出“重新生成奇偶校验”操作。后者将扫描所有磁盘，验证 RAID 奇偶校验和，并尝试通过重写任何具有读取错误或失败的 RAID 奇偶校验的块来恢复坏块。
另一方面，Compaq/HP 长期以来一直在对其 RAID 控制器执行后台扫描，如果无法从奇偶校验中自动恢复块/扇区，或者发现其他可疑情况，控制器会记录此情况，开始闪烁受影响驱动器的 LED 并尝试提醒管理员（例如，在 POST 期间显示一个烦人的消息屏幕）。我还没有听说我们目前拥有的大约 10,000 个 HP Smart Array 控制器（包括大约 1,100 个 P800）出现任何坏块问题。但是，这只是我的经验。