当我在一个RAID设置的硬盘上标记一个扇区为'有缺陷（GLIST）时会发生什么？
数据是立即写入replace部分还是取决于实际的设置/设置（软件/硬件RAID）？
示例：Raid 5 – 4驱动器 – Linux硬件Raid
在HDD 1扇区0x123456中断。 它被标记为有缺陷的。 这会导致该部门的数据被标记为丢失，现在该部门将指向供应商特定的数据。 但是由于raid包含1个副本，所以可以恢复有效的数据。
在哪个时刻，将恢复损坏的驱动器上的数据，从而再次有两组有效数据？
我想这是其中的一个：
如果确实是一个单独的问题/设置，那么我会对Smart Array P800特别感兴趣。
但请随时分享您所知道的任何事情。
PS：如果你通过googlefind这个smartmontools站点是一个很好的起点：例如http://smartmontools.sourceforge.net/badblockhowto.html#bb
依靠。
在日常业务中，您的硬盘会为每个正在写入的扇区写入校验和和一些ECC信息，并在读取操作期间validation这些数据。
如果错误足够小（例如，翻转位或其他小错误）将被硬盘的ECCfunction覆盖，则您的硬盘可能会自行恢复。 在SMART输出中仍然可以看到纠正的错误，但操作系统或硬件RAID控制器没有注意到读取错误。
否则，硬盘将向您的控制器报告不可恢复的读取错误，并在内部将该扇区标记为已损坏。 将数据写入相同（逻辑）扇区的尝试可让您的硬盘从保留扇区列表中分配replace扇区，并将逻辑扇区的访问透明映射到新的（replace）物理扇区。 您的写入请求将被存储在不同的物理扇区上，为您修复错误。
如果磁盘没有更换扇区，这也将失败，只能通过重写相同的逻辑扇区来恢复。
硬件RAID控制器通常通过执行背景媒体扫描，计划的自检以及validation存储的RAID奇偶校验的准确性，来尝试发现这种失败的扇区比通常的读取访问“更早”。
如果错误是通过重写来解决的，那么这个领域就是一个不同的故事，这个领域大部分都是没有logging的，而且大部分都取决于个人的经验。 从我十五年来的数十万台服务器上运行几十个不同厂商的硬件RAID控制器的经验来看，
作为“突破性进展”的一个例子，大约10年前，我在一个特定的控制器types的RAID 10configuration中遇到了严重的问题：甚至文件系统和应用程序数据被损坏。 更仔细的调查和在应用程序级别引入校验和表明，有时读取了零，但是已经期望非零数据。
罪魁祸首：从一个坏块读取时，控制器logging这个错误，但根本没有从工作副本恢复。 相反，它将周围的8k条数据报告为零条带，读取操作成功。 这种行为在大于100个控制器上是可重现的，供应商的客户支持甚至认为这是完全可以接受的，因为RAID只能从完全磁盘故障中恢复，而不能处理单个块的故障。
在RAID4 / RAID5configuration中，同一个控制器将从RAID冗余中恢复，并将恢复的条带传送到操作系统，但不会自动恢复磁盘上的坏块。 为了从坏块中恢复，需要在操作系统级重写相同的逻辑块，或者在pipe理界面中发出“重新生成奇偶校验”操作。 后者将扫描所有磁盘，validationRAID奇偶校验和，并通过重写任何具有读取错误或RAID奇偶校验失败的块来尝试恢复坏块。
另一方面，Compaq / HP一直在RAID控制器上进行背景扫描很长时间，如果块/扇区不能从奇偶校验中自动恢复，或者其他东西看上去很腥，控制器会logging下来，开始闪烁LED受影响的驱动器，并尝试提醒pipe理员（例如在POST期间通过唠叨的消息屏幕）。 我还没有听说我们目前拥有大约10k台惠普智能arrays控制器，包括大约1100台P800。 不过，这只是我的经验。