什么是SMART pre-fail预警
在RHEL系统中，smartd守护进程会定期检测硬盘的S.M.A.R.T.（Self-Monitoring, Analysis and Reporting Technology）自监控数据。当系统日志出现类似Device: /dev/sda, SMART Usage Attribute: 194 Temperature_Celsius changed from 117 to 114或者Attribute changed from 65 to 66这类信息，甚至在/var/log/messages中看到prefailure警告时，说明某块硬盘的关键健康属性已经越过阈值，进入了pre-fail（预故障）状态。pre-fail的含义是：这个属性一旦失效，硬盘会立即故障，而不是缓慢老化。
SMART属性分为两大类：一类是pre-fail属性，代表硬盘关键功能的健康度，例如重新分配扇区数、寻道错误率等，这类属性跌破阈值往往意味着硬盘很快会彻底损坏；另一类是old-age属性，代表正常老化指标，例如通电时间、启停次数，这类属性异常只说明硬盘寿命消耗，未必马上坏。因此当pre-fail属性报警时，运维人员必须高度重视，尽快安排处理。
smartd默认随smartmontools软件包安装，可以通过以下命令确认服务状态和配置：
systemctl status smartd rpm -q smartmontools # 查看smartd监控配置 cat /etc/smartmontools/smartd.conf
如何用smartctl查看并解读硬盘健康状态
处理预警的第一步是弄清楚到底是哪个属性出了问题。smartmontools提供的smartctl命令可以完整输出SMART属性表。常用命令如下：
# 查看硬盘整体健康状态 smartctl -H /dev/sda # 查看完整SMART信息，包括属性表和错误日志 smartctl -a /dev/sda # 针对RAID卡后面的硬盘，可能需要指定设备类型 smartctl -a -d megaraid,0 /dev/sda smartctl -a -d sat+megaraid,1 /dev/sda
如果smartctl -H输出结果为PASSED，只能说明当前尚未完全故障；如果输出FAILING NOW，则硬盘必须立即更换。但要注意，PASSED并不代表安全，pre-fail预警恰恰经常出现在PASSED状态下，因为属性值还只是接近阈值而非跌破阈值。
重点解读属性表中的ID_VALUE_WORST_THRESH三列。VALUE是当前归一化值，WORST是历史最差值，THRESH是厂商设定的失败阈值，VALUE接近或低于THRESH就触发预警。需要特别关注这几个pre-fail属性：
- Reallocated_Sector_Ct（05）：重新分配扇区数，该值持续增长说明盘面出现坏块并被备用扇区替换，是最典型的故障前兆。
- Current_Pending_Sector（C5/197）：待定不稳定扇区数，表示读写失败等待重试的扇区，只要不为零就值得警惕。
- Offline_Uncorrectable（C6/198）：离线不可修复扇区数，与197配合判断坏块严重程度。
- Seek_Error_Rate（07）与Spin_Retry_Count（10）：寻道错误与主轴启动重试次数，上升说明机械部件在退化。
另外，可以通过-smart=on确保SMART功能已启用，并使用smartctl -t long /dev/sda发起一次长时间自检，自检完成后用smartctl -l selftest /dev/sda查看历史自检结果，确认是否存在Offline或Completed with read failure之类的失败记录。
发现pre-fail预警后的标准处理流程
第一步永远是数据安全。确认是哪块盘出现预警后，立即评估该盘所在的位置：是单盘独立挂载，还是LVM成员，或者位于RAID阵列中。无论哪种情况，都应第一时间对关键数据进行完整备份。RAID阵列虽然提供冗余，但如果预警盘伴随着阵列中另一块盘的潜在问题，重建时可能触发二次故障，因此不要依赖冗余代替备份。
第二步是准备替换盘并评估更换时机。对于业务允许停机的场景，直接安排停机更换最稳妥。对于热插拔环境，操作顺序是：确认盘的物理槽位（可以通过RAID管理工具如storcli或MegaCLI定位）、将RAID卡上该盘设置为offline或直接拔出、插入新盘、等待阵列自动重建。重建期间务必避免同时对阵列做高负载写入，并持续监控重建进度：
# 使用storcli查看物理盘状态和槽位 storcli /c0 show # 单盘场景下，LVM可以用pvmove在线迁移数据 pvmove /dev/sdb1 /dev/sdc1 # 迁移完成后移除旧盘对应的物理卷 vgreduce datavg /dev/sdb1 pvremove /dev/sdb1
第三步是更换后的验证与监控闭环。新盘插入并重建完成后，用smartctl -a重新检查新盘的属性基线，确保Reallocated_Sector_Ct和Current_Pending_Sector均为零。同时在smartd.conf中配置邮件告警，让后续的pre-fail预警能自动通知到运维人员，避免再次依赖人工翻日志发现问题：
# smartd.conf示例：每日检测一次，故障时邮件通知 DEVICESCAN -a -d removable -m admin@ipipp.com -M exec /usr/share/smartmontools/smartd-runner # 修改后重启服务 systemctl restart smartd
容易被忽略的几个排查细节
首先是误报的可能。某些硬盘型号的固件对属性194温度或199等值的归一化方式不规范，会出现温度看起来异常的情况，此时应对照厂商提供的SMART属性说明文档判断。如果WORST值与VALUE相同且常年稳定，只是数值观感不佳，可以结合硬盘的通电时间和实际I/O错误（dmesg中的SCSI error、buffer I/O error）综合判断，避免盲目换盘造成浪费。
其次是RAID卡遮挡SMART数据的问题。LSI等RAID控制器默认会拦截直连的SMART命令，导致smartctl直接查询报错。这时必须通过-d megaraid,N参数指定逻辑编号，N是RAID卡视角下的物理盘编号而非OS的sd设备编号，两者要通过storcli的show输出对照确认，否则容易查错盘、换错盘，这是实际运维中最常见的低级失误之一。
最后是温度与供电环境。多次出现pre-fail预警的机房，往往伴随机柜散热不良或电源波动。更换硬盘只是治标，同时应检查服务器风扇状态、机房空调温度以及硬盘背板的供电稳定性。如果同一批次的硬盘在相近时间内陆续报警，还要考虑批次性缺陷，提前联系厂商核对固件版本和召回信息，把被动救火转变为主动排查。