Linux下用Smartctl检测硬盘健康状态

Linux下用smartctl检测硬盘健康状况远比简单查看`smartctl -H`是否返回PASSED复杂得多——该结果极易误导用户，因它仅依赖少数静态阈值，完全无法捕捉SSD早期磨损、备用块耗尽、不可纠正错误等真实风险；真正可靠的判断必须深入`smartctl -A`输出，区分NVMe（盯Percentage Used、Available Spare）与SATA SSD（看Media_Wearout_Indicator、Reallocated_Sector_Ct）的关键属性，并持续追踪其变化趋势；同时需警惕自检可能干扰SSD控制器、识别FAILING_NOW等临界告警、避免依赖无效参数，否则看似“正常”的硬盘可能已在数据丢失边缘。

smartctl -H 返回 PASSED 就安全？别信

很多用户看到 smartctl -H /dev/nvme0n1 输出 PASSED 就放下心，这是最危险的误判。SMART 整体健康评估只看几个关键阈值是否越界，而 SSD 的早期磨损、备用块耗尽、接口错误等根本不会触发它。真实风险藏在具体属性里，比如 Percentage Used（NVMe）或 Media_Wearout_Indicator（SATA SSD），这些值一旦接近 100%，即使 -H 还是 PASSED，也该立刻安排数据迁移。

SSD 关键属性怎么看：NVMe 和 SATA 完全不同

SSD 厂商对 SMART 属性命名不统一，必须按接口类型区分查看方式：

• NVMe 盘（如 /dev/nvme0n1）用 sudo smartctl -A /dev/nvme0n1，重点盯：Percentage Used（已用寿命百分比）、Available Spare（剩余备用块比例）、Available Spare Threshold（触发警告的下限）
• SATA SSD（如 /dev/sda）用同样命令，但关注：Media_Wearout_Indicator（越小越糟，典型安全值 >1）、Reallocated_Sector_Ct（非零即警讯）、Uncorrect（不可纠正错误数）
• 别看 Raw_Read_Error_Rate 或 Seek_Error_Rate —— 这些在 SSD 上无意义，数值受固件编码影响，跨盘不可比

执行自检前必须确认三件事

smartctl -t long 对 SSD 来说不是“慢”，而是可能干扰控制器后台任务，尤其在高负载时引发 I/O 卡顿甚至写入延迟飙升。执行前务必确认：

• 目标设备未被 dd、rsync、数据库进程直接读写（否则报 Device or resource busy）
• 不是系统根盘且未挂载为 / 或 /boot（部分 NVMe 驱动在自检中会短暂冻结队列）
• 先运行 smartctl -c /dev/nvme0n1 看是否支持 long 自检；老旧 USB-SATA 转接器或某些 PCIe 拓展卡常直接拒绝该命令

检测中用 smartctl -l selftest /dev/nvme0n1 查状态，结果不会自动落日志，必须手动提取。

发现 “FAILING_NOW” 或 “Pre-fail” 属性就停手

在 smartctl -A 输出里，如果任意一行的 WHEN_FAILED 列显示 FAILING_NOW 或 Pre-fail，说明该属性已跌破厂商硬阈值，硬盘处于故障临界点。此时：

• 立即停止写入，避免触发更多重映射或耗尽备用块
• 用 dd if=/dev/zero of=/tmp/test bs=1M count=100 快速验证写入是否稳定（若报 I/O 错误，基本可判定失效）
• 不要依赖 smartctl -X 中断自检——它对 NVMe 无效，有些 SATA SSD 也不响应

真正可靠的预警不是某次命令的结果，而是连续几天观察 Percentage Used 或 Available Spare 的变化趋势。跳变 2% 以上，就得当回事。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~