Reading SMART before the disk tells you

2026-09-21

smartctl -H answers a question nobody asked. "PASSED" means the drive's own thresholds were not crossed at the moment of the check, and several of those thresholds are set generously enough to be useless. The useful signal is the direction of a few counters over time.

Spinning disks

Four attributes are worth watching; the rest is mostly noise and vendor-specific re-interpretation of the same physical event.

• Reallocated_Sector_Ct — sectors moved to the spare pool. A stable non-zero value is an old scar. A value that grows between two checks is the disk telling you what it is doing right now.
• Current_Pending_Sector — sectors waiting to be reallocated because reads failed. These are the sectors that will surface as I/O errors, and they are the reason dmesg and SMART should be read together.
• Offline_Uncorrectable — sectors the self-test could not read and could not remap. Non-zero here means data loss already happened somewhere.
• Spin_Retry_Count and Reported_Uncorrect — rarer, unambiguous when they move.

Temperature matters less as an absolute and more as a change: a disk that used to idle at 34 °C and now idles at 44 °C has either lost airflow or is working harder than it was.

NVMe

NVMe does not use the old attribute table, and the things people carry over from spinning disks do not exist. The four that matter:

smartctl -a /dev/nvme0 | grep -Ei "Percentage Used|Available Spare|Data Units|Media and Data"

• Percentage Used — the vendor's own endurance estimate. Over 100 does not mean dead; it means the warranty claim is over.
• Available Spare — remaining spare blocks. A drop, or a value below the threshold in the same line, is the closest thing NVMe has to a real warning.
• Media and Data Integrity Errors — should be exactly zero. Any non-zero value is a conversation about replacement.
• Critical Warning — a bitmap; a non-zero value there is not something to monitor and wait on.

Scheduling the checks

# /etc/smartd.conf — short test daily at 02:00, long test first Saturday 03:00
/dev/sda -a -o on -S on -s (S/../.././02|L/../../6/03) -m root -M exec /usr/local/sbin/smart-alarm
/dev/nvme0 -a -s (L/../../6/03) -m root

Two things to get right in that line:

• The long test on a large disk takes hours and degrades performance while it runs. Schedule it when the machine is idle, and never on the same day as a filesystem scrub that reads the same disks.
• -m root alone silently does nothing on most modern systems, because local mail goes nowhere. Use -M exec with a script that appends to a log file or posts to something you read.

Two ways this goes wrong

USB and hardware RAID hide the data. A drive behind a bridge or a controller often reports nothing, or reports the bridge. Check with smartctl -d sat -a /dev/sdb for USB, and with the vendor's -d megaraid,N / -d cciss,N forms for controllers. A monitoring setup that gets "unable to get device identity" for three of six disks is monitoring three disks.

Self-tests pass while the kernel is already complaining. SMART asks the drive to self-report; the kernel sees failed I/O regardless of what the drive thinks. Read both:

journalctl -k --since "14 days ago" | grep -Ei "i/o error|medium error|ata[0-9]+\.[0-9]+|nvme[0-9]+: I/O"

← manuals