我的故事开始得非常简单。我有一台运行 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 处理得当，是时候订购替换磁盘了。我订购了一块新磁盘。
令我惊讶的是，一天后，错误......停止了。我没有做任何事情来修复它们。我没有重新启动，没有将驱动器脱机，什么都没有做。但错误就是停止了。
此时，出于好奇，想知道坏扇区是否只存在于磁盘的空闲部分，我将磁盘从 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”输出。只是有点长，所以我没有在这里发布。
答案1
如果驱动器表面的某个特定物理区域出现故障，那么在成功映射这些扇区之前，当您尝试读取写入该区域的任何数据时，您将收到无法恢复的读取错误。驱动器知道这些扇区是坏的（在访问这些扇区失败之后），但无法重新映射这些扇区，因为它们已经保存了数据。如果您格式化驱动器或覆盖“坏”扇区，那么驱动器将有机会映射出坏扇区。
一旦坏扇区被映射出来，并且只要更多的驱动器表面没有出现故障，就处于良好的状态。
我对当前驱动器的驱动器故障模型了解不够，不知道介质表面的某个部分损坏与问题蔓延或再次发生之间是否存在很大关联。如果没有关联，那么一旦坏扇区被映射出来，你就没问题了。如果有是那么这就是驱动力终结的开始。
答案2
大多数现代驱动器都会“矢量化”损坏的块。驱动器有一个备用块池，固件使用这些块替换驱动器已知的任何坏块。当驱动器无法读取某个块时，它无法执行这种重新映射，因为它无法提供正确的数据。它只会返回“读取错误”。它会将该块标记为坏块，因此如果该块确实读取正确，则该块将被矢量化，并将正确的数据写入替换块。如果操作系统曾经写入处于“矢量化待处理”状态的块，则该块将被矢量化，并将数据写入替换块。
Linux 软件 raid 会在从设备获取读取错误时，从阵列中的其他元素获取正确数据，然后尝试再次写入坏块。因此，如果写入成功，则数据是安全的，否则，驱动器只会执行上述操作，对块进行向量化，然后执行写入。因此，在 raid 系统的帮助下，驱动器已经自行修复！
假设此类事件相当罕见，那么继续进行可能是安全的。如果使用了太多替换块，则驱动器可能有问题。可以将多少替换块引导到备用块是有限制的，这取决于驱动器的功能。
答案3
是的，我也遇到过这种情况，而且情况非常相似。就我而言，是一块“消费级”西部数据 1TB“绿色”硬盘 (WD10EARS) 对我耍了这种花招。SMARTCurrent_Pending_Sector原始值从 0 变为 6，然后变为 8，促使 SMART 监控守护程序向我发送了一些不祥的电子邮件。
我从阵列中mdadm --fail取出--remove驱动器，并对其进行了非破坏性检查badblocks，是的，显然有超过 20 个坏块。大约一天后，替换驱动器到达，我修复了阵列，生活继续。
不久之后，出于无聊，我重新运行了badblocks“故障”驱动器，看看情况是否恶化。相反，驱动器已经完全“修复”了自己：没有坏块！我摇摇头，擦了擦，把它放在一边，等待回收或捐赠。
教训：不要在服务器中使用消费级驱动器，除非您愿意并能够忍受各种怪异和不可靠性。推论：不要在服务器组件上贪便宜，因为您最终还是要为它们付出代价，花费额外的时间和精力。
答案4
在服务器环境中，丢弃出现此类错误的驱动器（无论是否已修复）是一种常见的做法。扇区硬错误可能是介质表面物理损坏的迹象 - 如果您刮擦表面，通常会将材料移到刮擦的两侧，并使毛刺高于该表面的平面 - 或磨屑（玻璃！）。这两种情况往往对机械系统造成相当大的损害，因为机械系统依赖于两个表面之间非常薄的气垫，而这两个表面假设是完全光滑的……这就是为什么介质错误一旦开始达到一定数量，就会以更快的速度成倍增加。