How to Check Drive Health on Linux: smartctl Without the Guesswork

Drive monitoring · Published 2026-10-27 · Last updated 2026-10-27

SMART is the monitoring data a drive keeps about itself: wear, error counters, and whether any monitored value has crossed the threshold the firmware treats as failure. The Linux tool that reads it is smartctl, from smartmontools. A check takes four commands in a set order. Reading the output well takes one habit: trust the raw counters over the headline word.

That headline word is PASSED, and it is widely over-read. PASSED means the firmware is not reporting a current threshold failure. It does not rule out growing error counters, and it is not a promise about next month.

First: aim at the whole disk, never a partition

SMART data belongs to the physical disk, not to a partition. Use a whole-disk device such as /dev/sda or /dev/nvme0n1 with smartctl. A partition name such as /dev/sda1 is the wrong target: the counters live one level down, on the device itself.

Keep that distinction in every command below. Substitute your own whole-disk device for the examples.

The four commands, in order

Identify the drive. Run smartctl -i /dev/sda and confirm the model and capacity match the disk you mean to check. On NVMe, identity information targets the controller device: smartctl -i /dev/nvme0.
Read the headline verdict. Run smartctl -H /dev/sda. The result is PASSED or FAILED. A FAILED drive should be treated as failed without waiting for confirmation from any other reading.
Read the attributes or the health log. On a SATA drive, run smartctl -A /dev/sda and read the attribute table: ID, VALUE, WORST, THRESH, and RAW_VALUE. On NVMe, read the health log for the whole namespace device, /dev/nvme0n1; the fields differ, and the next sections cover them.
Run a self-test, then read its result. An extended test starts with smartctl -t long /dev/sda, and the result is checked afterwards with smartctl -l selftest. A test adds evidence; it does not replace the counters in step 3.

What success looks like: the identity matches the intended disk, the -H verdict is written down, the raw values for the decision counters below have been checked rather than skimmed, and any self-test result has been read with -l selftest. Four outputs, one dated record.

PASSED is not a verdict: the counters that decide

Analyse the RAW_VALUE column first. It is the primary figure. The normalised VALUE, WORST, and THRESH columns can mislead, because some manufacturers use non-standard normalisation; a tidy normalised score can sit beside a raw counter that is quietly climbing.

The replace signals are a short list. Growing values in any of these point the same way — copy the data off and replace the disk:

Reallocated_Sector_Ct — sectors the drive has already retired and replaced.
Current_Pending_Sector — sectors waiting, unreadable until they are rewritten or retired.
Offline_Uncorrectable — errors the drive could not correct.
Media and Data Integrity Errors — the NVMe-side counterpart, counted in the health log.
Available Spare dropping toward its threshold — the reserve running out.

One reading is a snapshot. Growth is the signal, which is why the dated record matters: the same counter higher at the next check is a decision already made.

NVMe: a different health log

NVMe drives do not present the ATA attribute table. Expect health-log fields instead, including percentage used, available spare, and media and data integrity errors. Judge them by the same logic as the SATA list: available spare falling toward threshold, and media errors appearing or growing, are copy-and-replace signals.

Percentage used needs calmer handling. It is a wear indicator to track over time, not a failure verdict on its own. Pair it with the spare and error fields before deciding anything.

Note the device-name split, because it trips people up. Identity information on NVMe targets /dev/nvme0, while SMART data for the namespace as a whole disk is addressed as /dev/nvme0n1. Both can be correct, for different commands.

Raw-value traps that are not failures

A high raw Hardware ECC Recovered count looks alarming and is not, by itself, a failure indicator. It is normal and informational, and high counts on Seagate drives are by design. Chasing that number alone can send a healthy drive to the bin.

The trap runs in both directions. A scary raw number may be routine for that maker, while a modest-looking counter on the decision list — reallocated or pending sectors — may be the real problem. Check the name of the counter before reacting to the size of the number.

For ongoing watch, smartd can alert on attribute changes, which beats remembering to re-run a manual check after the worry has faded.

When SMART is hidden: USB, RAID, and virtual disks

Try the SATA pass-through form for a USB-attached drive: smartctl -d sat -A /dev/sda, using your drive’s whole-disk device. Some USB bridges pass SMART through this way; many do not.
Read a refusal correctly. USB bridges, hardware RAID controllers, and virtual disks can hide SMART data. An unavailable result there is a limitation of the storage path, not evidence that the drive is healthy and not evidence that it has failed.
Change the path, not the conclusion. Connect the drive directly, or through a bridge known to pass SMART, and run the four commands again. Hardware RAID member drives need controller-specific pass-through, which sits outside this procedure; treat that as an administrator task for that controller, not a failed check.

The replace decision, stated plainly

Replace now: -H returns FAILED, or any decision counter is growing, or available spare is dropping to threshold. Copy data first, in priority order, then replace.

Keep and monitor: PASSED, decision counters flat between dated checks, and only known-benign raw values — the ECC pattern above — are high. Set the next check date when you record this one.

No verdict yet: SMART is hidden by the connection path. Fix the path and re-check before calling the drive either way.

— Dex Carter, Tech Writer

Back to all guides →