我们有一个已经使用了3年的linux服务器。 我们正在运行一些虚拟化的服务器，其中一些服务器的performance不佳，并且在相当长的一段时间内，服务器的IO容量已经超出，导致了糟糕的Iowait。 它有4 500克梭子鱼SATA驱动器连接到3COM RAID控制器。 1个驱动器有操作系统，其他3个安装RAID-5。
现在我们就驱动力的状况和是否积极失败进行辩论。
这是4个磁盘中的一个的一部分输出。 他们都有相对相似的统计数据：
SMART属性数据结构修订号：10 具有阈值的供应商特定SMART属性： ID＃ATTRIBUTE_NAME标记值最差值types已更新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 Power_On_Hours 0x0032 069 069 000 Old_age始终 - 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 Always - 1 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 071 060 045 Old_age始终 - 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始终为0 SMART错误日志版本：1 没有错误logging
我对此的解释是，我们没有任何坏道或其他迹象表明任何驱动力都在积极失败。
但是，高Raw_Read_Error_Rate和Seek_Error_Rate指向驱动器正在死亡的指示。
根据我的经验，Seagate对这两个SMART属性有奇怪的数字。 在诊断希捷时，我倾向于忽视这些，并更仔细地看待其他领域，如重新分配的扇区计数。 当然，如果有疑问取代驱动器，但即使全新的希捷也将拥有很高的这些属性。
对于Seagate磁盘（也可能是WD的一些旧的磁盘），Seek_Error_Rate和Raw_Read_Error_Rate是48位数字，其中最重要的16位是错误计数，低32位是一些操作。
% python >>> 200009354607 & 0xFFFFFFFF 2440858991 >>> (200009354607 & 0xFFFF00000000) >> 32 46 所以你的磁盘执行了2440858991个寻道，其中46个失败了。 我对希捷硬盘的使用经验是，当错误数量超过1000时，他们往往会失败。
除了希捷的支持外，对于任何人来说，“寻找错误率”和“原始读取错误率”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数据已经成为失败预测的一个相当薄弱的指标，正如Google发表的一篇研究论文所揭示的那样。
是的，这些领域看起来不好，但我不相信（智能报告）（我的testing机器有一个驱动器，如果你用smartctrl读取数据应该会死的很久以前）事实是，你已经报告高艾奥瓦和驱动器是3岁。 这应该足以让你改变驱动器。
我意识到这个讨论已经有点老了，但是想要增加我的2美分。 我发现这些智能信息是相当好的预失败指标。 当你得到一个智能阈值绊倒，然后更换驱动器。 这就是这些门槛的目的。
绝大多数时候你会看到坏道。 这是一个肯定的迹象，驱动器开始失败。 SMART为我节省了很多次。 我使用软件RAID 1，它非常有用，因为您只需更换故障驱动器并重buildarrays即可。
我也每周都进行短期和长期的自我检测。
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并将rootredirect到一个电子邮件地址，然后检查logwatch的每日电子邮件。 SMARTD绊倒的旗帜将出现在那里，但如果没有人经常监视它，这是没有帮助的。