工具的“良好”两个字几乎没有预测价值。这篇文章讲清每个关键字段是什么意思、NVMe 的剩余寿命百分比是怎么算出来的,以及为什么 USB 硬盘盒和 RAID 模式下根本读不到。
每个 SMART 属性都带三个数:value(当前归一化值,出厂通常是 100 或 200 多)、worst(历史最低)、thresh(阈值)。驱动和工具判“良好”的唯一依据是 value 还没跌破 thresh。
问题在于厂商把这个阈值设得极低,常见是 10,甚至 0。也就是说:归一化值从 100 掉到 20 的整个过程,工具都显示“良好”;掉到 10 时才第一次报故障。而机械盘和固态盘在这个区间里已经死过不止一次了。
所以健康度那一行字,本质是“已经出事了”的事后报警,不是预测。要判断一块盘稳不稳,看的是几个关键计数器的绝对值与变化率:重映射扇区从 0 变成 1,和从 40 变成 41,是完全不同的两件事,前者往往意味着盘面出现了真实退化,后者可能已经稳定运行了三年。
Windows 没有统一的“SMART API”。工具拿到这些数据要走三条路之一,一般都需要管理员权限打开物理驱动器句柄(\\.\PhysicalDriveN):
| 接口 | 适用 | 说明 |
|---|---|---|
| 早期 SMART 专用接口 | SATA / ATA | Windows 最早提供的通道,一次取回完整的属性表与阈值表,但对新盘型支持有限 |
| ATA 直通命令 | SATA / ATA | 把 ATA 命令原样下发给盘,能绕开老接口的限制,也能问到更多厂商自定义属性 |
| 存储属性查询 | NVMe | 按协议类型请求 NVMe 的健康日志,字段由规范固定 |
这三条路都要求数据从物理设备直接上来。中间每多一层(USB 桥片、RAID 驱动、虚拟化层),就多一次“它愿不愿意转发”的选择:桥片可能只实现了一部分 ATA 命令,RAID 驱动可能把这些查询自己接管了,虚拟化层也可能没把设备交给虚拟机。透传一旦不完整,读回来的就是空白——下一节的“读不到”多半是这个原因,与软件好坏关系不大。
实践中这几条路往往要一起用,并且必须各自设超时。原因有两类:一是不同盘型只认其中某一条,例如有的 NVMe 盘只在“存储属性查询”下返回健康日志,走 ATA 那套什么也拿不到;二是个别 SATA 盘对 ATA 直通命令的超时不作响应,一条命令可以挂住好几秒,逐盘遍历就会把界面卡在启动阶段。所以读硬盘这类操作的通行做法是:单条查询设短超时、失败就换一条通道、再不行才放弃——而不是死等一个接口。
ATA 的 SMART 表有 30 个属性位,但绝大多数是厂商自定义。真正跨品牌可比的只有下面这几个,其余字段换一个品牌含义就变了,不要套用。
| ID | 名称 | 含义 | 什么算异常 |
|---|---|---|---|
| 05 | Reallocated_Sector_Ct | 已用备用扇区顶替掉的坏扇区数 | 任何非零都该记录在案;持续增长说明盘面在退化 |
| 09 | Power_On_Hours | 累计通电小时 | 不判异常,用于判断盘的实际年龄与使用强度 |
| 0C | Power_Cycle_Count | 累计开关机次数 | 与通电小时比值异常(极频繁)时关注供电与休眠设置 |
| B7 | Reported_Uncorrect | 无法纠正的读写错误次数 | 大于 0 就要开始备份,这是已经发生过读失败 |
| C5 | Current_Pending_Sector | 读写时读不出来、等待重映射的弱扇区 | 最该盯的一项,非零代表此刻就有数据可能读不出 |
| C6 | Offline_Uncorrectable | 离线自检中无法纠正的扇区 | 非零且增长=盘面物理损伤,不是逻辑错误 |
| C7 | UDMA_CRC_Error_Count | 接口传输校验失败次数 | 涨了先换 SATA 线,这一项几乎从不是盘本身的问题 |
| BE / C2 | Airflow / Temperature | 气流温度与盘体温度(raw 低字节是当前摄氏度) | 长期高于 50 ℃ 会显著缩短寿命 |
| F1 / F2 | Total_LBAs_Written / Read | 主机累计读写的逻辑扇区数 | 乘 512 字节即为累计写入量,用于估算 SSD 磨损 |
机械盘和固态盘的关注点完全不同:机械盘看 05、C5、C6(盘面与磁头),固态盘看磨损与写入量(F1、以及下面 NVMe 那一套),C7 则两类都要看一眼——它指向的是线材和接触,不是盘。
NVMe 没有“属性 ID”这套东西,它是一张固定结构的健康日志(Log Page 0x02),字段含义由规范定义,所以跨品牌可以直接比较,这比 SATA 那套干净得多。
| 字段 | 含义 | 怎么读 |
|---|---|---|
| Critical Warning | 关键告警位图 | 任何一位非零都要立刻处理,例如备用空间耗尽、可靠性降级、已进入只读模式 |
| Available Spare | 可用备用空间百分比 | 低于厂商阈值(下一项)即触发告警,代表坏块已吃掉大半余量 |
| Available Spare Threshold | 备用空间告警阈值 | 厂商设定,通常 10%,两者一起看才有意义 |
| Percentage Used | 已消耗寿命百分比 | 厂商估算值,见下一节,这是唯一接近“剩余寿命”的字段 |
| Data Units Written | 累计写入的数据单元数 | 1 单元 = 1000 × 512 字节,乘完才是字节数,别直接当扇区算 |
| Media and Data Integrity Errors | 介质与数据完整性错误 | 非零且增长=闪存层出了真实错误,比任何百分比都严重 |
| Unsafe Shutdowns | 非正常断电次数 | 过多会加速映射表损坏,笔记本常因强制关机累积 |
| Power On Hours | 累计通电小时 | 与写入量一起,用来判断这块盘的使用强度 |
换算写入量的公式要记住单位:TBW(太字节)= Data Units Written × 512000 ÷ 10¹²。少乘这 1000 倍,你会算出“写了几百 GB 就消耗了 40% 寿命”这种明显矛盾的结论——这是最常见的误读。
还有一项厂商差异极大的可选字段:NAND 累计写入量(ATA 的 SMART 0xE9)。只有定义了这条属性的 SATA 固态才有它,NVMe 规范里没有等价字段。HwDetect 的磁盘页对这类可选字段的处理是“有就显示、没有就连那一行都不出现”,而不是填 0 或写“未知”——后者会让人误以为“这块盘的写入量极低”,恰好把最该警惕的情况看成了最健康的情况。
先说结论:这个百分比不是测出来的,是厂商按模型估出来的。规范原文的措辞就是“厂商对已消耗寿命的估计值”,各家的模型、参数、更新时机都可以不一样。
Percentage Used:综合 P/E(编程/擦除)循环次数与主机写入量,对照厂商对这块盘标称的耐久度来外推。它跟的是闪存的实际磨损,不是主机写了多少。231(SSD_Life_Left,raw 多是剩余百分比)或 233(Media_Wearout_Indicator,Intel 系)。方向因品牌而异,有的 raw 是“已用”,有的是“剩余”,不能跨品牌套用。还有两个让显示值和你手算对不上的原因:
Percentage Used 跟的是闪存那一侧,所以它下降得比你按 TBW 算的快,这是正常的。所以正确的用法是:在你自己的盘上标定一次——记下当前写入量与 Percentage Used,一个月后再看一次,得出“我这块盘每消耗 1% 对应多少 GB 写入”。这个系数比任何通用表格都准,因为它来自你自己的使用场景。
这件事的前提是两个数得同时在场:主机累计写入量,和盘自己报的已用寿命。HwDetect 的磁盘页把 Total Host Writes、Percentage Used、以及(存在的话)NAND 写入量放在同一组里,就是为了标定时不用在两个界面之间来回抄数——抄错一次,算出来的系数就废了。
| 现象 | 真实原因 | 怎么办 |
|---|---|---|
| USB 硬盘盒里的盘,只有容量没有健康度 | 桥片不转发 ATA PASS-THROUGH(SAT)命令,SMART 请求被吞掉 | 换支持透传的桥片或直连 SATA;USB 接 NVMe 需要 UASP 且桥片支持透传 |
| 开启 RAID 后所有盘的健康度空白 | 盘被 RAID 驱动接管,标准 IOCTL 拿不到物理设备 | 用主板 RAID 管理工具查;或临时切 AHCI 交叉验证 |
| 虚拟机 / 云主机里读不到 | 虚拟磁盘通常没有真实 SMART 数据可透传 | 多数需要在物理机上确认;部分平台支持设备直通 |
| 提示“拒绝访问”或读回全零 | 未以管理员身份打开物理驱动器句柄 | 以管理员运行;确认程序拿到的是 PhysicalDriveN 而非盘符 |
还有一种不在这张表里:刚热插拔完立刻读。此时设备树还没重新枚举完,句柄能打开但读回失败,等几秒重试即可,不必怀疑盘坏了。
还有一条容易被忽略的判断原则:空白和 0 是两件事。读不到时应当留空,而不是补 0——把“没有数据”渲染成“重映射扇区 0 个”,会让一块正在退化的盘看起来完全正常。HwDetect 的磁盘页对读不到的字段直接不生成那一行,就是为了让“缺失”本身一眼可见。
只读,不向磁盘写入任何数据,也不修改 SMART 设置。USB 桥接与 RAID 模式下能否读取取决于硬件是否透传。