硬盘读取错误…停止了吗？

我的故事很简单。我有一台运行Arch Linux的轻型服务器，该服务器将大多数数据存储在由两个SATA驱动器组成的RAID-1上。它正常工作了大约四个月。然后，突然我开始在其中一个驱动器上出现读取错误。总是，消息看起来像这样：

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

每个错误都抱怨扇区号不同，并伴随用户（me）访问磁盘几秒钟的延迟。

我检查了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

因此，让我感到奇怪的部分是，“坏磁盘何时才能修复？”

我想这很可能是驱动器的一个很小的区域自发地坏了，并且该驱动器只花了三天（！）才启动其扇区重新分配代码，并在磁盘的坏区域上映射了一些备用扇区...但是我不能说我曾经见过这种情况。

其他人看到过这种行为吗？如果是这样，那之后您对驱动器有何经验？又发生了吗？磁盘最终是否会完全失效？还是只是无法解释的故障？

就我而言，我已经有替换驱动器（在保修期内获得），因此无论如何我都可能只是替换驱动器。但是我很想知道我是否以某种方式误诊了。如果有帮助，从问题发生时起，我将获得完整的'smartctl -a'输出。它有点长，所以我没有在这里发布。

如果驱动器表面的一个特定物理区域变坏，则在可以成功映射这些扇区之前，尝试读取写入该区域的任何数据时，都会出现无法恢复的读取错误。驱动器知道扇区损坏（在无法访问扇区之后），但是无法重新映射扇区，因为它们已经保存了数据。如果格式化驱动器或覆盖“坏”扇区，则驱动器将有机会映射出坏扇区。

一旦坏扇区被映射出来，并且只要更多的驱动器表面不会发生故障，您就处于良好状态。

我对当前驱动器的驱动器故障模型了解不足，无法知道介质表面的一部分变坏与问题扩散或再次发生之间是否存在很大的相关性。如果没有相关性，则一旦坏扇区被映射出来，您就处于良好状态。如果是相关性，那么这是最终的驱动的开始。

大多数现代驱动器都会“引导出”已损坏的块。该驱动器具有一个备用块池，固件使用这些备用块来替换该驱动器已知有问题的任何块。当驱动器无法读取块时，由于无法提供正确的数据，因此无法执行此重新映射。它只是返回“读取错误”。它会将块标记为不良，因此，如果该块确实读取正确，则该块将被引导出，并将正确的数据写入替换块。如果操作系统曾经写过处于“向量输出未决”状态的块，则该向量将被向量出并将数据写入替换块。

从设备读取错误时，Linux软件团队将从阵列中的其他元素获取正确的数据，然后尝试再次写入坏块。因此，如果写入正常，则数据是安全的；否则，驱动器仅执行上述操作，对块进行矢量处理，然后执行写入操作。因此，驱动器已经在RAID系统的帮助下进行了自我修复！

假设此类事件相当罕见，那么进行下去可能是安全的。如果使用过多的更换块，则驱动器可能有问题。可以将多少个替换块引导到备用块有一个限制，这取决于驱动器。

是的，在非常相似的情况下，我也看到了这一点。以我为例，这是一个“消费级”西部数据1TB“绿色”驱动器（WD10EARS），给我带来了麻烦。SMART Current_Pending_Sector原始值从零变到6，然后又变到8，促使SMART监视守护程序向我发送一些不祥的电子邮件。

我从阵列中mdadm --fail读取并--remove驱动了该驱动器，并对其进行了无损检查badblocks，是的，显然有超过2打坏块。大约一天后，当替换驱动器到达时，我修理了阵列，然后继续生活。

此后不久，由于无聊，我badblocks再次尝试“失败”的驱动器，看看它是否恶化了。相反，驱动器本身已完全“修复”：零坏块！摇了摇头，我擦了擦头，将其放在一边以便回收或捐赠。

课程：不要在服务器中使用消费级驱动器，除非您愿意并且能够忍受各种奇怪和不可靠的情况。结论：不要便宜服务器组件，因为最终您最终还是要为它们付出更多的时间和麻烦。

在服务器环境中，通常的做法是丢弃曾经显示出此类错误的驱动器，无论是否已修复。扇区硬错误可能是介质表面物理损坏的标志-如果刮擦表面，通常会将材料移到刮擦的侧面，并获得比此类表面高的毛刺-或研磨性粉尘（玻璃！ ）。两者都倾向于对机械系统造成相当大的损害，这种机械系统依赖于假设为非常光滑的两个表面之间非常薄的气垫。这就是为什么一旦开始达到一定数量的中等误差往往会更快地繁殖。