How to check SSD and NVMe health on Linux
Solid-state drives rarely fail loudly. They report their own wear, their own overheating and their own unclean shutdowns in a log you can read in two commands. This guide covers both commands and what each line means.
Two tools, one log
Every drive keeps a SMART log (Self-Monitoring, Analysis and Reporting Technology). On Linux there are two ways to read it:
- smartmontools (
smartctl) reads SATA and NVMe drives and is the tool most distributions document. Install it withsudo apt install smartmontools,sudo dnf install smartmontoolsorsudo pacman -S smartmontools. - nvme-cli (
nvme) speaks the NVMe protocol directly and prints the health log with its original field names. Install withsudo apt install nvme-cli(or the equivalent).
Both need root, because reading the log is a raw command to the device. That is also why Innards asks for your password only for this one probe.
First, find your drives:
lsblk -d -o NAME,MODEL,SIZE,ROTA,TRAN
# ROTA 1 = spinning disk, 0 = solid state. TRAN = sata, nvme, usb
NVMe drives: nvme smart-log
sudo nvme smart-log /dev/nvme0
The output is one field per line. The ones worth reading, in the order you should read them:
critical_warning- A bitmask;
0is what you want. Any other value means the drive itself is raising a flag: spare blocks below threshold, temperature out of range, the media has become read-only, or a backup-power failure. Treat non-zero as "back up today". percentage_used- The controller's own estimate of how much of the drive's rated endurance has been consumed, based on how much has been written and how the NAND is holding up. 0 is new; 100 means the rated write endurance has been reached. It can go past 100, which does not mean the drive is dead, only that it is now living beyond its warranty figure. Innards flags wear as worth fixing once it is high and says: past 80%, plan a replacement.
available_spareandavailable_spare_threshold- Spare blocks, as a percentage of the reserve the drive shipped with. When
available_sparefalls below the threshold (often 10%) the critical warning bit is set. A healthy drive sits at 100% for years; a falling number means blocks are being retired. media_errors- Unrecovered data-integrity errors: reads that the controller could not correct. This should be zero. Any non-zero value is a replace-soon signal, and it usually gets worse.
unsafe_shutdownsandpower_cycles- An unsafe shutdown is a power loss the drive was not warned about. A handful over a drive's life is normal; every held power button or pulled plug counts. What matters is the ratio. On the ThinkPad that started Innards, the drive had logged 69 unsafe shutdowns, a large share of its power cycles, which pointed at something real: the machine was hanging at reboot. On DRAM-less NVMe drives that use the host's memory as a buffer (HMB), a high count often means the controller is not coming out of its deepest power-saving state cleanly at shutdown. The kernel parameter
nvme_core.default_ps_max_latency_us=0disables those deep states and is the standard workaround; it costs a little idle power. temperature,warning_temp_time,critical_comp_time- Current composite temperature, plus two counters in minutes: time spent above the warning threshold and time spent above the critical one (the thresholds vary by drive; around 80°C is typical for the warning). The same ThinkPad's drive had logged 270 minutes above critical over its life because the M.2 bay had no thermal pad. Above critical, a drive throttles itself to survive, so this shows up as intermittent slowness long before it shows up as failure.
data_units_writtenandpower_on_hours- Lifetime writes, in units of 1,000 × 512 bytes (multiply by 512,000 for bytes, or by roughly 0.5 for megabytes), and hours powered. Together with
percentage_usedthese tell you how the drive has been treated: a low wear figure after years of hours is a drive with plenty of life left.
You can run the drive's built-in self-test as well; it checks the media without touching your data:
sudo nvme device-self-test /dev/nvme0 -s 1 # short test
sudo nvme self-test-log /dev/nvme0 # results
SATA SSDs (and hard drives): smartctl
sudo smartctl -H /dev/sda # overall verdict: PASSED or FAILED
sudo smartctl -a /dev/sda # everything, including the attribute table
smartctl -a also works on NVMe (/dev/nvme0) and prints the same health log as nvme smart-log with slightly friendlier labels. On SATA drives the interesting part is the attribute table, where the raw value column is what to read:
- 5 Reallocated_Sector_Ct, 197 Current_Pending_Sector, 198 Offline_Uncorrectable: bad blocks, blocks waiting to be checked, and blocks that failed. All three should be 0. Innards adds these together with NVMe media errors into one "bad sectors" finding, because they mean the same thing: back up, then replace.
- 199 UDMA_CRC_Error_Count: transfer errors on the cable, not on the drive. A rising count means a bad SATA cable or connector.
- Wear: SATA SSDs report it under vendor-specific names, commonly 177 Wear_Leveling_Count, 231 SSD_Life_Left or 233 Media_Wearout_Indicator. Some count down from 100, some count up;
smartctlusually normalises it so that the "VALUE" column falling towards the "THRESH" column is the warning. - 194 Temperature_Celsius, 9 Power_On_Hours, 12 Power_Cycle_Count: what they say.
A short self-test takes a couple of minutes and does not interrupt use:
sudo smartctl -t short /dev/sda
sudo smartctl -l selftest /dev/sda # a few minutes later
Which numbers actually mean "replace"
SMART data invites over-reading. Keep it to four questions:
- Does the drive say it is failing?
critical_warningnon-zero, orsmartctl -Hreporting FAILED. Back up today, replace this week. - Is it losing data? Media errors, reallocated, pending or uncorrectable sectors above zero. Back up, then replace; it gets worse.
- Is it worn out?
percentage_usedpast 80%, or a SATA life indicator approaching its threshold. Plan a replacement and keep backups current. It is not an emergency. - Is it being mistreated? Lots of unsafe shutdowns, or minutes logged above critical temperature. The drive is probably fine; the machine around it is not. Fix the reboot hang, add a thermal pad, clean the fan.
Everything else on the list is context. A ten-year-old SSD at 30% wear with zero errors is healthier than a two-year-old one with three pending sectors.
Drives behind USB
SMART over a USB enclosure depends on the bridge chip. smartctl can often get through with -d sat (SATA drives) or -d sntjmicron / -d sntrealtek (NVMe drives, depending on the bridge). If nothing works, the drive may still be perfectly healthy; the enclosure simply does not pass the commands.