我的故事开始很简单。 我有一台运行Arch Linux的轻型服务器，它将大部分数据存储在由两个SATA驱动器组成的RAID-1上。 4个月左右没有任何问题。 然后，突然间，我开始在其中一个驱动器上读取错误。 总是，这些消息看起来很像这些：
Apr 18 00:20:15 hope kernel: [307085.582035] ata5.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Apr 18 00:20:15 hope kernel: [307085.582040] ata5.01: failed command: READ DMA EXT Apr 18 00:20:15 hope kernel: [307085.582048] ata5.01: cmd 25/00:08:08:6a:34/00:00:27:00:00/f0 tag 0 dma 4096 in Apr 18 00:20:15 hope kernel: [307085.582050] res 51/40:00:0c:6a:34/40:00:27:00:00/f0 Emask 0x9 (media error) Apr 18 00:20:15 hope kernel: [307085.582053] ata5.01: status: { DRDY ERR } Apr 18 00:20:15 hope kernel: [307085.582056] ata5.01: error: { UNC } Apr 18 00:20:15 hope kernel: [307085.621301] ata5.00: configured for UDMA/133 Apr 18 00:20:15 hope kernel: [307085.640972] ata5.01: configured for UDMA/133 Apr 18 00:20:15 hope kernel: [307085.640986] sd 4:0:1:0: [sdd] Unhandled sense code Apr 18 00:20:15 hope kernel: [307085.640989] sd 4:0:1:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Apr 18 00:20:15 hope kernel: [307085.640993] sd 4:0:1:0: [sdd] Sense Key : Medium Error [current] [descriptor] Apr 18 00:20:15 hope kernel: [307085.640998] Descriptor sense data with sense descriptors (in hex): Apr 18 00:20:15 hope kernel: [307085.641001] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 Apr 18 00:20:15 hope kernel: [307085.641010] 27 34 6a 0c Apr 18 00:20:15 hope kernel: [307085.641020] sd 4:0:1:0: [sdd] Add. Sense: Unrecovered read error - auto reallocate failed Apr 18 00:20:15 hope kernel: [307085.641023] sd 4:0:1:0: [sdd] CDB: Read(10): 28 00 27 34 6a 08 00 00 08 00 Apr 18 00:20:15 hope kernel: [307085.641027] end_request: I/O error, dev sdd, sector 657746444 Apr 18 00:20:15 hope kernel: [307085.641035] ata5: EH complete Apr 18 00:20:15 hope kernel: [307085.641672] md/raid1:md16: read error corrected (8 sectors at 657744392 on sdd1) Apr 18 00:20:17 hope kernel: [307087.505082] md/raid1:md16: redirecting sector 657742336 to other mirror: sdd1 每个错误都抱怨不同的扇区号码，并伴随着用户（我）访问磁盘几秒钟的延迟。
我检查了smartctl输出，并看到下面的输出（不相关的部分剪辑）：
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 193 193 051 Pre-fail Always - 1606 5 Reallocated_Sector_Ct 0x0033 194 194 140 Pre-fail Always - 0 196 Reallocated_Event_Count 0x0032 162 162 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 51
回顾一下日志，我发现这些错误实际上已经发生了几天，主要是在备份过程中，但是也经常在非常轻的使用期间（这意味着大约每隔5次我试图保存一个文本文件）。 我的结论是，我的磁盘正在死亡，RAID-1正在处理它，是时候订购一个replace磁盘。 我点了一个新的磁盘。
令我惊讶的是，一天之后，错误停止了。 我没有做任何修理。 我没有重新启动，没有离线驾驶，没有。 但错误刚刚停止。
那时候，好奇的是，现在坏扇区是否处于空闲状态，我把磁盘从RAID中取出，放回到RAID中，然后让它完成随后的完全同步。 重新同步完成没有任何错误，9小时后（2TB磁盘需要一点点）。
此外，smartctl输出已经改变了一下，如下所示：
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 193 193 051 Pre-fail Always - 1606 5 Reallocated_Sector_Ct 0x0033 194 194 140 Pre-fail Always - 43 196 Reallocated_Event_Count 0x0032 162 162 000 Old_age Always - 38 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
所以，这个让我感觉到的部分当然是，“从什么时候坏磁盘修理好自己？
我想可能是驱动器的一个很小的区域自发地变坏了，而驱动器在其扇区重新分配代码启动之前仅花了3天（！），并且在磁盘的不良区域映射了一些备用扇区。但是我不能说我见过这样的事情。
有没有人看过这种行为？ 如果是这样，那么以后你的驾驶经验是怎样的？ 它又发生了吗？ 磁盘最终是否完全失败？ 还是只是一个原因不明的故障，仍然是无法解释的？
在我的情况下，我已经有更换驱动器（保修期内获得），所以我可能只是更换驱动器。 但是我很想知道我是否以某种方式误诊了。 如果有帮助，我可以从问题发生的时候完成“smartctl -a”输出。 这只是有点长，所以我没有在这里发表。
如果驱动器表面的某个特定物理区域出现故障，那么直到这些扇区可以成功映射出来，当您尝试读取写入该区域的任何数据时，您将看到未被发现的读取错误。 驱动器知道扇区是坏的（在访问扇区失败之后），但是因为已经保存了数据而不能重映射扇区。 如果格式化驱动器或覆盖“坏”扇区，则驱动器将有机会映射出坏扇区。
一旦坏扇区被映射出来，并且只要更多的驱动器表面没有失效，那么你的状态良好。
我不太了解当前驱动器的驱动器故障模型，以了解介质表面一部分变坏与问题扩散或再次发生之间是否存在很多相关性。 如果没有相关性，那么一旦坏扇区被映射出来，你的状态就很好。 如果存在相关性，那么这是驾驶结束的开始。
大多数现代的驱动器将会“向量化”一个坏块。 该驱动器有一个备用块池，固件使用这些来replace驱动器已知的任何块是坏的。 无法读取块时，驱动器无法进行重新映射，因为无法提供正确的数据。 它只是返回“读取错误”。 它将块标记为坏，所以如果块确实读取正确，则块被向量化并且将正确的数据写入到replace块中。 如果操作系统曾经写入一个处于“向量悬空”状态的块，那么该块被向量化，数据被写入到replace块中。
Linux软件RAID会在从设备读取错误时从数组中的其他元素获取正确的数据，然后尝试再次写入坏块。 所以，如果写入工作正常，那么数据是安全的，如果没有，驱动器只是做到了上述，vector块，然后执行写入。 所以，在RAID系统的帮助下，驱动器已经自行修复了！
假设这样的事件相当罕见，继续进行可能是安全的。 如果使用的replace块过多，则驱动器可能有问题。 有多lessreplace块可用于备用块，并且是驱动器的function是有限制的。
是的，我也看到了这一点，在非常相似的情况下。 在我的情况下，这是一个“消费级”西数1TB“绿色”驱动器（WD10EARS），拉我的特技。 SMART Current_Pending_Sector原始值从零变为6，然后变为8，提示SMART监控守护程序向我发送一些不祥的电子邮件。
我mdadm --fail和 – 从arrays中mdadm --fail驱动器，并运行一个非破坏性的坏块通过它，是的，显然有二十多个坏块。 当更换的驱动器在一天后到达时，我固定arrays，生命继续。
此后不久，出于纯粹的无聊，我在“失败”的驱动器上重制了坏块，看看它是否恶化了。 相反，驱动器已经完全“修复”了自己：零坏块！ 摇着头，我擦了一下，放在一边回收或捐赠。
教训：不要在服务器上使用消费级驱动器，除非你愿意且能够忍受各种怪异和不可靠。 推论：不要在服务器组件上低价出售，因为无论如何你最终还是要为它们付出代价。
在服务器环境中，通常的做法是丢弃曾经显示过这样的错误的驱动器。 扇区硬误差可能是物理表面损伤介质的一个标志 – 如果您刮擦表面，您通常会将材料置于刮擦的两侧，并使毛刺高于此类表面的平面 – 或磨屑（玻璃！ ）。 两者往往是相当有害的机械系统，依靠两个表面之间非常薄的气垫假设完全平滑…这就是为什么中等错误，一旦他们开始达到一定数量倾向于更快地繁殖。