The protocol gap: SMART vs NVMe Health Information
SMART (ATA/SCSI attribute framework) and NVMe health telemetry are not just different names for the same data. They are structurally different reporting systems with different data models, different failure taxonomy, and different granularity. The distinction matters for prediction because the signals you read, and what those signals mean for each protocol, require separate interpretation frameworks.
SMART on SATA drives reports a set of numbered attributes, each with a normalized value (1-253), a worst-case value retained since manufacture, and a raw value in a format that varies by vendor. The failure threshold is vendor-defined. Your monitoring reads the normalized value and compares it against the threshold. That is the complete data model.
NVMe drives report a Health Information log page (NVMe 1.3 spec, Section 5.14.1.2). This is a structured binary log page with named fields: critical warning byte, composite temperature, available spare percentage, available spare threshold, percentage used, data units read and written since manufacture, host read and write commands since power-on, controller busy time, power cycles, power on hours, unsafe shutdowns, media and data integrity errors, number of error information log entries, and warning composite temperature time. These are precisely defined fields, not vendor-mapped attribute slots.
When a monitoring tool reads NVMe drives through an ATA-passthrough SMART emulation layer (via smartctl -a /dev/nvme0 using the SCSI/ATA translation layer, for example), it translates NVMe health fields into ATA SMART attribute slots. The mapping is imperfect. Available spare maps to attribute 12. Percentage used maps to attribute 177. Media and data integrity errors map to attribute 187. But the calculation behind each field differs from what those attribute numbers mean on a SATA drive. If your monitoring system applies SATA attribute thresholds to NVMe-sourced values in those slots, you are applying the wrong interpretation.
How SATA SSD failure signatures present in SMART telemetry
SATA SSDs using TLC or MLC NAND tend to exhibit failure signatures that develop gradually and are detectable via multiple attribute trajectories before the final failure event. The pattern we observe most consistently involves three converging signals.
Reallocated sector count (attribute 5) begins increasing. On SATA SSDs, a reallocated sector corresponds to a retired NAND block that the drive has identified as unreliable and replaced from the spare pool. Early-stage block retirement is normal. What is predictive is an acceleration in the retirement rate. A drive that has retired 0 blocks for two years and then retires 8 in three weeks is on a different trajectory than a drive that has accumulated 12 blocks steadily over the same period.
Pending sector count (attribute 197) rises concurrently with or slightly before reallocated count on many failure trajectories. Pending sectors are blocks flagged for reallocation that have not yet been remapped. They represent blocks the drive has identified as potentially unreliable but has not yet been able to remap (either because no read request has triggered the remap, or because the spare pool is low). A rising pending count with no corresponding rise in reallocated count is a signal that the spare pool may be insufficient to keep up with block retirement demand.
Reported uncorrectable errors (attribute 187) appears in the late stage of many SATA SSD failure trajectories. By the time attribute 187 is non-zero, the drive is beyond early failure detection. It is a late-stage confirmation signal, not an early-warning signal. Monitoring setups that alert only on attribute 187 are catching failures that are already close.
The combined trajectory of attributes 5, 197, and 187 across a SATA SSD failure typically spans 2 to 5 weeks. Attribute 5 velocity starts first, often 3 to 4 weeks before failure. Attribute 197 follows. Attribute 187 appears last. A model that detects attribute 5 velocity anomalies can provide useful lead time. A model that waits for attribute 187 cannot.
NVMe failure signatures: a different anatomy
NVMe drives fail through overlapping mechanisms with SATA SSDs at the NAND level, but the telemetry signatures present differently because the health reporting schema captures different variables.
The most common pre-failure trajectory on NVMe drives in our telemetry starts with available spare percentage declining faster than expected for the reported write workload. Available spare is the percentage of the drive's spare NAND block pool remaining. When spare blocks run low, the drive cannot remap failing blocks, read amplification increases, and write performance degrades. The decline rate of available spare is predictive weeks before the spare threshold drops below the drive's self-reported warning level.
Media and data integrity errors is the NVMe field with the most direct correspondence to late-stage SATA failure signals. Like attribute 187, it counts reads and writes where the controller could not correct the error through ECC. But on NVMe drives, this field tends to appear earlier in the failure trajectory relative to the final failure event compared to SATA attribute 187. NVMe drives with a single non-zero media error count warrant immediate attention, whereas SATA attribute 187 at 1 or 2 is less definitively severe on all drive models.
Controller busy time (a cumulative counter in NVMe health logs) can surface controller-level stress. A drive whose controller busy time is growing faster than its host command count suggests internal retry and error-handling overhead is increasing. This is a signal not available in SATA SMART and often precedes both media errors and spare depletion on NVMe failure trajectories we have observed. It is underutilized in most monitoring implementations because most monitoring tools do not collect it.
Power cycle count velocity is more significant on NVMe drives than on SATA in storage server environments. NVMe drives in high-density NVMe enclosures can be exposed to more power transients than SATA drives with dedicated power connectors. Drives showing an elevated power cycle rate relative to their normal operational cadence (which can indicate enclosure-level power instability) tend to accumulate unsafe shutdowns, and the combination of elevated power cycle rate plus non-zero unsafe shutdown count is an early signal we track specifically on NVMe fleet segments.
Model training implications: you cannot pool them
The practical consequence of the protocol difference for prediction model design is that NVMe and SATA telemetry require separate model training, or at minimum separate feature engineering pipelines with protocol-aware normalization before a shared model layer.
If you pool NVMe and SATA drive telemetry and train a single model without protocol-level normalization, the model learns a weighted average of two different failure taxonomies. It will perform well on the protocol that contributes more training examples and poorly on the other. More problematically, it will find spurious correlations between SMART attribute values and failures that are actually NVMe-origin events and vice versa, degrading interpretability of the feature importance ranking.
The input features for the NVMe model include: available spare decline rate, media data integrity error velocity, controller busy time growth rate, unsafe shutdown count, and power cycle rate. The input features for the SATA model include: attribute 5 velocity, attribute 197 trend, attribute 177 decline trajectory, attribute 187 count, and command timeout rate. The overlap in feature semantics between protocols is partial, not complete. Treating them as the same feature set by name introduces cross-protocol noise.
Per-model calibration within each protocol group is also necessary. A Samsung 970 Pro NVMe has different baseline distributions for media error rate and available spare decline than a Micron 7300 Pro NVMe. Applying the same alert threshold to both produces different false positive rates on each model family. Within the NVMe protocol group, model-family stratification matters for threshold calibration even though the feature schema is standardized.
Where the gap narrows and where it does not
The failure signature gap between NVMe and SATA narrows in one specific area: NAND wear-out near rated endurance. Both protocols surface endurance signals (attribute 177 or 233 for SATA, percentage used and available spare for NVMe), and the fundamental mechanics of NAND cell wear are the same regardless of the interface. A drive approaching its P/E cycle limit will show accelerating error rates and spare depletion regardless of whether it is SATA or NVMe. The late-stage trajectories look structurally similar even though the attribute numbers and field names differ.
The gap does not narrow for controller-level failures and firmware-driven issues. NVMe controller failures often present first in latency histogram degradation (a field in the NVMe 1.4 latency statistics log page) and controller busy time anomalies, signals with no SATA equivalent. SATA drive controller failures often present in error recovery count and command abort patterns that do not have an NVMe equivalent. These failure modes require protocol-specific detection logic that does not translate across the interface boundary.
For SRE teams running mixed SATA and NVMe fleets, the operational implication is that a single monitoring agent configured with uniform attribute thresholds will have meaningfully different recall on the two protocol families. Getting to reliable failure prediction on both requires acknowledging that the telemetry schemas are different, training or configuring prediction logic separately for each, and validating alert performance on each family independently rather than relying on a combined accuracy figure that may mask poor performance on one protocol.
What to do before your model is ready
If you are not yet running a trained prediction model and are working from threshold-based monitoring, the minimum protocol-aware setup looks like this:
For SATA SSDs: monitor attributes 5, 197, 187, and 177 as separate time series rather than just checking their current value. Set alert conditions on 7-day delta for attribute 5 and attribute 197 rather than on absolute values. Alert on any non-zero attribute 187. Alert on attribute 177 declining faster than 5 normalized points per month.
For NVMe: query the Health Information log page directly rather than relying on ATA-passthrough SMART emulation. Monitor available spare decline rate (weekly delta), media and data integrity errors (any non-zero count is signal), and unsafe shutdown count (any increase is worth examining). Controller busy time growth rate is worth collecting even if you do not have a model for it yet.
Neither of these is a substitute for trajectory-based predictive modeling, but they are meaningfully more informative than applying identical thresholds to all drives regardless of protocol. The protocol distinction matters for every layer of the monitoring stack, from what data you collect to how you alert on it to how you train models against it.