☰

如何解释此 smartctl (smartmon) 数据

tag-icon • tag-icon linux smartctl
如何解释此 smartctl (smartmon) 数据

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

现在我们正在讨论驱动器的状况以及它们是否正在主动发生故障。

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

SMART 属性数据结构修订号：10
供应商特定的 SMART 属性及阈值：
ID# ATTRIBUTE_NAME 标志值 最差阈值类型 已更新 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 始终 - 26
  5 Reallocated_Sector_Ct 0x0033 100 100 036 预故障始终 - 0
  7 Seek_Error_Rate 0x000f 077 060 030 始终预失败 - 200009354607
  9 通电时间 0x0032 069 069 000 老化时间始终 - 27856
 10 Spin_Retry_Count 0x0013 100 100 097 预失败始终 - 1
 12 Power_Cycle_Count 0x0032 100 100 020 Old_age 始终 - 26
184 Unknown_Attribute 0x0032 100 100 099 Old_age 始终 - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age 始终 - 0
188 Unknown_Attribute 0x0032 100 100 000 Old_age 始终 - 1
189 High_Fly_Writes 0x003a 100 100 000 Old_age 始终 - 0
190 Airflow_Temperature_Cel 0x0022 071 060 045 Old_age 始终 - 29（生命周期最小值/最大值 26/37）
194 温度_摄氏度 0x0022 029 040 000 Old_age 始终 - 29 (0 21 0 0)
195 Hardware_ECC_Recovered 0x001a 046 033 000 Old_age 始终 - 169074425
197 Current_Pending_Sector 0x0012 100 100 000 Old_age 始终 - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age 离线 - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age 始终 - 0

SMART 错误日志版本：1
未记录任何错误

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

然而，较高的 Raw_Read_Error_Rate 和 Seek_Error_Rate 表明驱动器正在损坏。

答案1

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

答案2

对于 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。

答案3

除了 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 逻辑内部计算的，确切的计算结果可能会或可能不会由制造商公布，并且通常无法由用户调整。

就我个人而言，我认为包含错误日志条目的驱动器“出现故障”，并敦促在出现故障时立即更换。但总的来说，SMART 数据已被证明是一个相当弱的故障预测指标，因为谷歌发表的研究论文裸露。

答案4

我意识到这个讨论有点过时了，但我想补充一下我的看法。我发现智能信息是预故障的一个很好的指标。当智能阈值被触发时，请更换驱动器。这就是这些阈值的用途。

绝大多数情况下，您都会开始看到坏扇区。这是驱动器开始出现故障的明确信号。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 触发标志将显示在那里，但如果没有人定期监控它，它就毫无用处。

相关内容