What the NVMe health log can see: five warning bits, a few counters, and the failures that show up elsewhere

The log answers a narrow question well: has the drive itself declared that spare capacity, temperature, reliability, write access or backup power has crossed a line. Each of those five conditions has a defined bit, and the Microsoft reference and the Linux header agree on the bit order. The two numbers that look like life gauges are softer than they appear: Percentage Used is a vendor estimate that is allowed to exceed 100 and, at 100, 'may not indicate an NVM subsystem failure', and Available Spare is a normalised percentage with no information about where the weak blocks are.

In the one large public NVMe fleet study, the warning bits were rarely set: 99.97% of valid critical-warning readings were zero, and in the baseline table the median critical-warning value is 0 for each of the 22 model and capacity rows. Of the tickets that recorded a cause, 14.15% were drives whose SMART values crossed a threshold; 49.55% were I/O failures, 19.59% boot failures, 11.07% link failures and 5.65% lost drives. The source does not say how many of the I/O, boot, link or lost cases had an earlier health-log signal, so this page does not claim any.

Slow drives are the clearest documented miss. The same study found no clear correlation between fail-slow behaviour and SMART attributes (including Critical Warning, program/erase error and CRC error) in any of 40 groups, and concluded that the root causes or symptoms of fail-slow are not well captured by SMART. That is a statement about that fleet and those attributes, not about every drive.

Counters can run far ahead of any warning bit. In Google's flash fleet, between 96.1% and 99.9% of drives per model saw a correctable error, between 20.3% and 90.5% an uncorrectable error and between 0.57% and 5.20% a final write error in four years. Whether the standard media-error counter moves for each of these is vendor-specific and neither source says; what the NVMe log can promise is only that the media-error count covers uncorrectable ECC, CRC and tag-mismatch events. For a failure that matters at the time it happens, the kernel's per-command status (Table 5) and the controller's own error log are the finer-grained records, and link and path faults are named in a different status class from media errors.