如何解释此smartctl（smartmon）数据

我们有一个使用了三年的Linux服务器。我们正在其上运行许多虚拟化服务器，其中一些表现不佳，并且在相当长的时间内，服务器的io容量超出了容量，导致iowait故障。它有4个500GB梭子鱼SATA驱动器连接到3com RAID控制器。1个驱动器有操作系统，其他3个是安装RAID-5。

现在，我们就驱动器的状态以及驱动器是否正在发生故障进行辩论。

这是4个磁盘中的1个磁盘的部分输出。它们都有相对相似的统计数据：

SMART Attributes Data Structure修订版号：10
具有阈值的供应商特定的SMART属性：
ID＃ATTRIBUTE_NAME标记值最坏的阈值类型已于WHEN_FAILED RAW_VALUE更新
  1 Raw_Read_Error_Rate 0x000f 118099006始终预失败-169074425
  3 Spin_Up_Time 0x0003 095092000总是故障前-0
  4 Start_Stop_Count 0x0032 100100020始终老龄-26
  5 Reallocated_Sector_Ct 0x0033 100100036预故障始终-0
  7 Seek_Error_Rate 0x000f 077060030始终预失败-200009354607
  9 Power_On_Hours 0x0032 069069000始终有老人年龄-27856
 10 Spin_Retry_Count 0x0013 100100097始终预故障-1
 12 Power_Cycle_Count 0x0032 100100020始终老龄-26
184 Unknown_Attribute 0x0032 100100099老年总是-0
187 Reported_Uncorrect 0x0032 100100000 Old_age Always-0
188 Unknown_Attribute 0x0032 100100000始终老龄-1
189 High_Fly_Writes 0x003a 100100000老年总是-0
190 Airflow_Temperature_Cel 0x0022 071060045始终老龄-29（终生最低/最高26/37）
194 Temperature_Celsius 0x0022 029 040 000 Always Old_age Always-29（0 21 0 0）
195 Hardware_ECC_Recovered 0x001a 046033 000 Always Old_age Always-169074425
197 Current_Pending_Sector 0x0012 100100000老年总是-0
198 Offline_Uncorrectable 0x0010 100100000老年离线-0
199 UDMA_CRC_Error_Count 0x003e 200200 000老龄始终-0

SMART错误日志版本：1
没有记录错误

我对此的解释是，我们没有任何坏道，也没有其他迹象表明任何驱动器正在发生故障。

但是，高的Raw_Read_Error_Rate和Seek_Error_Rate表示驱动器快要死了。

以我的经验，希捷有这两个SMART属性的怪异数字。在诊断Seagate时，我倾向于忽略这些内容，而更仔细地查看其他字段，例如“重新分配的扇区数”。当然，如果有疑问，请更换驱动器，但是即使是全新的希捷，这些属性也会有很高的数量。

对于Seagate磁盘（可能还有WD的一些旧磁盘），Seek_Error_Rate和Raw_Read_Error_Rate是48位数字，其中最高16位是错误计数，而低32位是许多操作。

% python
>>> 200009354607 & 0xFFFFFFFF
2440858991
>>> (200009354607 & 0xFFFF00000000) >> 32
46

因此，您的磁盘已执行2440858991搜索，其中46次失败。我对Seagate驱动器的经验是，当错误数超过1000时，它们往往会失败。YMMV。

除了Seagate的支持外，“搜索错误率”和“原始读取错误率” RAW_VALUES几乎毫无意义。正如其他人指出的那样，诸如“重新分配的扇区数”之类的参数的原始值或驱动器的错误日志中的条目更可能表明出现故障的可能性更高。

但是您可以看一下VALUE，WORST和THRESH列中的解释数据，这些数据将被视为量表：

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH
  7 Seek_Error_Rate         0x000f   077   060   030

这意味着您的寻道错误率当前被认为是“ 77％良好”，当达到“ 30％良好”时，SMART会将其报告为问题。曾经曾经低至“ 60％良好”，但此后就神奇地恢复了。请注意，解释值是由驱动器的SMART逻辑内部计算的，确切的计算结果可能会也可能不会由制造商发布，并且通常不能由用户进行调整。

就个人而言，我认为包含错误日志条目的驱动器为“失败”，并敦促在出现错误后立即进行更换。但总而言之，正如Google发表的研究论文所揭示的那样，SMART数据已被证明是故障预测的相当薄弱的指标。

我意识到这次讨论有些陈旧，但想加2美分。我发现智能信息可以很好地指示故障前。当智能阈值跳闸时，请更换驱动器。这就是这些阈值的目的。

绝大多数时间，您将开始看到不良扇区。这是驱动器开始出现故障的肯定迹象。SMART救了我很多遍。我使用RAID 1软件，它非常有用，因为您只需更换出现故障的驱动器并重建阵列即可。

我还每周进行一次简短的自我测试。

smartctl -t short /dev/sda
smartctl -t long /dev/sda 

或将其添加到/etc/smartd.conf并在出现错误时通过电子邮件发送给您

/dev/sda -s L/../../3/22 -I 194 -m someemail@somedomain
/dev/sdb -s L/../../7/22 -I 194 -m someemail@somedomain

确保安装logwatch并将root重定向到电子邮件地址，并检查来自logwatch的每日电子邮件。SMARTD跳闸的标志将在那里显示，但是如果没有人定期监视它，没有帮助。

是的，这些字段看起来很糟糕，但是我不信任（不再）smart报告的信息（如果您使用smartctrl读取数据，我的测试机上的驱动器应该会在很久之前失效）。高iowait，驱动器已使用3年。这足以让您更换驱动器。

很抱歉在这篇文章上发表文章，但以我的经验，Seagate硬盘的“原始读取错误率”和“已恢复硬件ECC”字段实际上会遍地开花，并不断地增加到万亿范围。将循环回到零以再次继续该过程。我有一个Seagate ST9750420AS，从第一天开始就遇到了这个问题，即使经过3500年以上的使用和使用，它仍然可以正常工作。

我认为，如果您要运行一个字段，可以安全地忽略这些字段。只需确保两个字段报告相同的数字并不断同步即可。如果他们不是...嗯...那实际上可能意味着一个问题。

要自动计算此答案，请使用在线javascript计算器：

https://yksi.ml/

这将告诉您：

• 作业总数
• 操作失败次数

该计算器适用于希捷的：

• 寻求错误率
• 原始读取错误率
• 恢复硬件ECC

有关标准化（在0到100之间的值）的计算的更多信息，请参见本文。