Context
An NVMe device's health report contains several independent signals: wear estimates, spare capacity, media errors, temperature, and critical-warning bits. A single overall status cannot explain every performance or reliability concern. Read the fields in context, preserve their trend, and confirm which physical device the report describes.
Establish device and tool identity
Record controller and namespace identifiers, model, serial number, firmware, capacity, host slot or enclosure mapping, and the application using the device. Device numbering can change across reboot, so connect every health observation with stable identity.
Use the installed nvme-cli or vendor-supported tool's current help. Newer upstream nvme-cli documentation distinguishes the newer nvme log smart form from older nvme smart-log usage. Match the command to the installed version rather than treating a changed command name as a drive failure.
Health collection is different from formatting, firmware activation, or destructive tests. A routine monitoring procedure should request the required logs without modifying device configuration or application data.
Interpret wear as an estimate
Percentage Used is an endurance-consumption estimate defined through the device's implementation and specification. It is not a countdown predicting the exact day the drive will fail. Review vendor endurance guidance and workload writes alongside it.
Available spare and its threshold provide another health dimension. Critical-warning bits can indicate specific conditions that require interpretation rather than a generic red or green label. Preserve the raw value and the matching specification or vendor explanation.
Do not compare two different models' wear percentages as if they guarantee identical remaining life. Capacity, endurance rating, firmware behavior, and write pattern affect the meaning of the observation.
Read errors and temperature as trends
Media and data-integrity errors, error-log entries, unsafe shutdowns, and controller-busy time describe different events. A cumulative count needs timestamps and deltas. An old count that remains stable is different from a rapidly increasing count during an incident.
Correlate thermal observations with workload latency, throughput, cooling, and any supported thermal-management counters. A brief current temperature reading may miss an earlier thermal event. Conversely, a warm device is not proof that throttling caused a particular application delay.
Include host kernel messages, PCIe or controller-path evidence, and filesystem errors when diagnosing I/O failures. A device health log alone may not describe a faulty cable, enclosure, host connection, or broader storage-stack problem.
An illustrative premature replacement
A team sees a high wear estimate and assumes it explains every slow query on a server. The estimate has been stable, while query latency coincides with a changed access pattern and CPU work. A separate device with a lower wear estimate is accumulating new media errors.
The team separates performance diagnosis from replacement planning. It prioritizes the active error trend and protects recoverability, while investigating the query workload independently. The result is a risk-based hardware decision supported by evidence rather than one percentage.
Quick diagnostic map
| Evidence | Question | Next check |
|---|---|---|
| Wear estimate rises steadily | Is endurance consumption expected? | Writes and vendor rating |
| New media errors appear | Is data or device reliability degrading? | Error log, kernel, and backup state |
| Latency follows thermal events | Is cooling limiting operation? | Temperature history and workload |
| Host I/O errors; SMART looks unchanged | Is the path involved? | Controller, PCIe, and storage stack |
A focused operator exercise
Collect a baseline health log for a test device with verified identity. Repeat during a representative bounded workload and after it cools down. Record timestamps, tool version, raw fields, application throughput, and latency without changing firmware or device state during the comparison.
Rehearse the replacement workflow using disposable storage or the vendor's supported test process. Verify the operator can identify the correct slot, restore protected data, and validate application output. The receipt should distinguish a monitoring threshold from proof of failure and a replacement from proof of data recovery.
Plan replacement before the emergency
Assign owners to critical warnings, growing error counts, and endurance planning. Maintain spare compatibility, firmware policy, backup access, and a known maintenance window. Recheck redundancy before removing any member of an array.
Frequently asked questions
Does Percentage Used predict exact remaining lifetime?
No. Treat it as an implementation-specific endurance estimate and combine it with vendor guidance and observed trends.
Does a clean health log prove the whole storage path is healthy?
No. Correlate controller, host, filesystem, and application evidence when diagnosing I/O problems.
Continue the investigation
- Degraded Linux RAID: Identify Members Before Recovery
- Linux Iowait: Connect CPU Accounting to Storage Evidence
Browse the cloud, server and infrastructure guide library for related operational questions.
Explore Clouvenix NAS, SAN & File Server Infrastructure to discuss implementation, validation and operational handover.
Technical reference
nvme-cli/Documentation/nvme-smart-log.html at master · linux-nvme/nvme-cli · GitHub