如何解释这个 smartctl (smartmon) 数据

Question

我们有一台已经使用了 3 年的 Linux 服务器。我们在其上运行了许多虚拟化服务器，其中一些表现不佳，并且在很长一段时间内超出了服务器的 io 容量，导致 iowait 错误。它有 4 个 500gb 的 Barracuda sata 驱动器连接到 3com raid 控制器。1个驱动有操作系统，其他3个设置raid-5。

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

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

SMART 属性数据结构修订号：10
具有阈值的供应商特定 SMART 属性：
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate 0x000f 118 099 006 总是预失败 - 169074425
  3 Spin_Up_Time 0x0003 095 092 000 总是预失败 - 0
  4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 26
  5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
  7 Seek_Error_Rate 0x000f 077 060 030 总是预失败 - 200009354607
  9 Power_On_Hours 0x0032 069 069 000 Old_age Always - 27856
 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 1
 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 26
184 Unknown_Attribute 0x0032 100 100 099 Old_age Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
188 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 1
189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0022 071 060 045 Old_age Always - 29（终身最小/最大26/37）
194 Temperature_Celsius 0x0022 029 040 000 Old_age Always - 29 (0 21 0 0)
195 Hardware_ECC_Recovered 0x001a 046 033 000 Old_age Always - 169074425
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0

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

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

然而，高 Raw_Read_Error_Rate 和 Seek_Error_Rate 被指向作为驱动器正在死亡的迹象。

Answer 1

对于希捷磁盘（可能还有一些来自 WD 的旧磁盘），Seek_Error_Rate 和 Raw_Read_Error_Rate 是 48 位数字，其中最重要的 16 位是错误计数，低 32 位是一些操作。

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

所以你的磁盘已经执行了 2440858991 次搜索，其中 46 次失败。我对希捷硬盘的经验是，当错误数量超过 1000 时，它们往往会失败。YMMV。

Answer 2

“搜索错误率”和“原始读取错误率”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 逻辑在内部计算，确切的计算可能会或可能不会由制造商发布，并且通常无法由用户调整。

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

Answer 3

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

Answer 4

添加这些标志，以便属性 1 和 7（Raw_Read_Error_Rate 和 Seek_Error_Rate）被解释为由 24 位错误计数和 32 位总计数组成。

\n

-v 1,raw24/raw32 -v 7,raw24/raw32\n

\n

-v代表--vendorattribute=

\n

指定 raw24/raw32 是告诉 smartctl 按照通用格式解释和显示原始信息的一种方法。请参阅手册页。

\n

按照此处的希捷手册 每个属性的原始 7 字节含义如下

\n

Attribute ID 1: Raw Error Rate  \nRaw [3 \xe2\x80\x93 0] = Number of sector reads  \nRaw [6 - 4] = Number of read errors  \n\nAttribute ID 7: Seek Error Rate  \nRaw [3 \xe2\x80\x93 0] = Number of seeks  \nRaw [5 \xe2\x80\x93 4] = Number of seek errors\n

\n

Answer 5

我意识到这个讨论有点老了，但想加我的 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 跳闸标志会出现在那里，但如果没有人定期监视它就无济于事。