How to Check Disk Health on Linux: smartctl, nvme smart-log and the Three Metrics That Matter

CodexFuse Team · 2026-11-04T10:01:45.156Z · 12 min read min read

A drive can look fine and be dying. This guide shows the full Linux disk-health workflow: lsblk device discovery, the smartctl -H verdict, the three metrics that actually predict failure, the NVMe smart-log, and why VPS virtual disks report nothing at all.

Learning how to check disk health in Linux is the difference between replacing a drive on your schedule and losing data on the drive's schedule. A disk can pass every filesystem check and still be dying underneath: df tells you the disk is full, but only S.M.A.R.T. data tells you the disk is failing — and reading it takes one package install. This guide walks the full check on any distro: find the drive with lsblk, get the 30-second verdict with smartctl -H, read the three metrics that actually predict failure, handle NVMe drives with the native smart-log, and understand why a VPS hosting virtual disk reports no health data at all.

How Do I Check Disk Health on Linux?

Find the device with lsblk, install smartmontools, run smartctl -H for the verdict, and read the key attributes with smartctl -A (or the NVMe smart-log). The complete workflow is:

1. lsblk -d -o NAME,SIZE,MODEL,TRAN — find the real device name (/dev/sda, /dev/nvme0) so you query the disk, not a partition.
2. sudo apt install smartmontools (or dnf / pacman) — the smartctl toolkit.
3. sudo smartctl -H /dev/sda — the 30-second boolean verdict: PASSED or FAILED.
4. sudo smartctl -A /dev/sda — read the three killer metrics: Reallocated_Sector_Ct, Current_Pending_Sector, Offline_Uncorrectable.
5. sudo nvme log smart /dev/nvme0 — the native NVMe health log for SSDs (check nvme --version first: 3.0+ uses this form).

The rest of this guide explains what each command actually reports — and the one rule that stops a PASSED verdict from giving you false confidence.

What Is S.M.A.R.T., and What Does smartctl Do?

S.M.A.R.T. — Self-Monitoring, Analysis and Reporting Technology — is a monitoring system built into the firmware of most ATA/SATA, SCSI/SAS, and NVMe drives. As the smartctl man page puts it, its purpose is "to monitor the reliability of the hard drive and predict drive failures, and to carry out different types of drive self-tests." smartctl is the command-line tool (from the smartmontools package) that reads that firmware data; smartd is its companion daemon that watches drives continuously in the background.

The key mental model: S.M.A.R.T. data is predictive, not reactive. The drive counts its own bad sectors, timeouts, and errors over its lifetime, and smartctl surfaces those counters. When you check SSD health Linux-style, you are not benchmarking the drive — you are reading its diary.

Step 1: Find the Real Device With lsblk

Every smartctl command needs the device node of the whole disk — /dev/sda, not /dev/sda1, because a partition has no SMART data of its own. The cleanest discovery command is:

lsblk -d -o NAME,SIZE,MODEL,TRAN

The -d flag lists disks only (no partitions); the columns show the name, size, model, and transport (sata, nvme, or — tellingly — virtio on a virtual machine). On a server with an NVMe drive you will see nvme0n1; the matching controller node is /dev/nvme0, which is what the NVMe commands in step 5 target.

If several disks appear, the MODEL column is your friend: match it to the drive you physically installed, or to the volume your host's panel shows. Guessing the device is the one beginner mistake that wastes an afternoon.

Step 2: Install smartmontools

The smartctl Ubuntu install takes one command, and the package lives in every major distro's repositories. One version note from the man page's NVMe guidance: versions before 6.6 have incomplete NVMe support, so on a modern server running NVMe SSDs you want smartmontools 7.x or later — any current distro ships that.

sudo apt install smartmontools        # Debian / Ubuntu
sudo dnf install smartmontools        # RHEL 8+, Fedora, AlmaLinux, Rocky
sudo yum install smartmontools        # RHEL / CentOS 7
sudo pacman -S smartmontools          # Arch Linux

Run smartctl with sudo: it talks directly to drive firmware, and without elevated privileges it cannot open the device (you get a permission error, not a health report). For NVMe drives also install nvme-cli — same package managers, same package name.

Step 3: The 30-Second Verdict — smartctl -H

Run the overall-health self-assessment first. It returns one word: PASSED or FAILED. A real capture (from FOSS Linux's smartmontools walkthrough) looks like this:

$ sudo smartctl -H /dev/sda
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Here is the rule you must internalize once, because it reframes everything else: a PASSED result does not mean the drive is healthy. The man page is explicit — -H only checks the boolean SMART RETURN STATUS: if the device reports failing health, it has "either already failed, or it is predicting its own failure within the next 24 hours." PASSED means no manufacturer threshold has been crossed yet — nothing more. For NVMe drives the verdict comes from the Critical Warning byte of the SMART/Health log instead, but the logic is identical.

If the verdict is FAILED, the man page's instruction is blunt: "get your data off the disk and to someplace safe as soon as you can." Treat a FAILED drive as failed — do not wait for a second opinion.

smartctl -a Explained: Read the Three Metrics That Matter

The real audit lives in the attributes table. smartctl -A prints the vendor-specific SMART attributes; smartctl -a prints the full report. One verified nuance worth knowing: guides often claim lowercase -a equals -H -i -c -A -l error -l selftest — that expansion is exact for NVMe drives, but the current man page shows the ATA expansion adds -l selective as well. Either way, -a is the standard "give me everything" command when diagnosing an unfamiliar drive.

Each attribute row carries a normalized VALUE, a WORST, a THRESH (threshold), and a RAW_VALUE. The rule from the man page: if the normalized value is less than or equal to the threshold, the attribute has failed. For failure prediction, though, you mostly watch the raw counters — and of the 253 possible attributes, Backblaze's drive-farming experience distills the watchlist to five. These five counters are the classic signs of failing disk Linux servers show before anything else, and three of them are the killers:

That is the reallocated sector count meaning in one line: it is the drive's own confession that parts of its surface have gone bad. A handful of reallocated sectors on an old drive is history; a count that grows between two checks a week apart is a countdown.

Two more flags round out the toolkit: smartctl -t short runs a quick self-test (usually under ten minutes) and smartctl -t long scans the whole surface (tens of minutes to hours) — both can run during normal operation, and smartctl -l selftest shows the results. Run the short test monthly and the long test quarterly; never start a long test on a drive you already suspect is failing until the data is copied off, because the test itself stresses the drive.

NVMe SSDs: Read the Native smart-log

NVMe drives do not use ATA attributes — they expose a native SMART / Health Information log, and the tool that reads it best is nvme-cli. One 2026 change to know: nvme-cli 3.0 (released September 2026, per the tiespecialistas NVMe guide) renamed the log commands, so the old nvme smart-log form is now a deprecated alias that prints a warning. Check nvme --version first, then:

sudo nvme log smart /dev/nvme0      # nvme-cli 3.0+
sudo nvme smart-log /dev/nvme0      # nvme-cli 2.x (deprecated alias in 3.0)

The device naming is exact and worth getting right: /dev/nvme0 is the controller, /dev/nvme0n1 is a namespace (block device) on it. The health log is controller-level — both forms are accepted, but the controller node is the canonical target. smartctl reads the same log with sudo smartctl -a /dev/nvme0, which is handy when you already live in smartmontools.

A typical healthy report looks like this (from FOSS Linux's smartmontools walkthrough):

Critical Warning:                   0x00
Available Spare:                    100%
Percentage Used:                    2%
Data Units Read:                    12,456,789 [6.37 TB]
Power On Hours:                     1,245

Four fields do the heavy lifting. Critical Warning is a bit field — zero is the normal state, and any non-zero value must be decoded bit by bit (spare below threshold, temperature threshold, degraded NVM reliability, read-only media, and two more). Percentage Used is the endurance gauge: a vendor estimate of NVM life consumed. The spec language is careful here — a value of 100 means the estimated endurance is consumed but "may not indicate an NVM subsystem failure," and the value is allowed to exceed 100. Treat the percentage used NVMe reading as a fuel gauge, not a failure probability. Available Spare is the remaining spare NAND as a percentage; Media and Data Integrity Errors should be zero, always.

And the honest caveat, stated once: SMART data cannot guarantee advance warning. An NVMe SSD can fail abruptly even when its previous health readings looked normal — which is why the metrics inform your backup schedule instead of replacing it.

Why smartctl Shows Nothing on Your VPS

If you run smartctl -i on a typical VPS and get "SMART support is: Unavailable — device lacks SMART capability," nothing is broken. Your virtual machine sees a virtual disk, not the host's physical drive: as one Proxmox admin put it, "your VM only sees a virtual disk... SMART won't be available inside the guest as the VM doesn't got access to the real physical hardware." Virtual disks do not pass S.M.A.R.T. data through to the guest — the smartctl man page itself notes that virtual disks "typically have no useful information to convey."

So what can you monitor on a VPS? The host handles drive health; your job is everything above the virtual disk: keep an eye on capacity with a regular disk space check on Ubuntu (a full disk and a dying disk produce eerily similar symptoms), watch I/O latency, and keep backups you have actually tested. If you run bare metal or a dedicated server, the full smartctl workflow above applies as written.

Make It Continuous: smartd and the Scrutiny Dashboard

A one-time check catches today's problems; a daemon catches next month's. smartd, the monitoring daemon in the smartmontools package, watches your drives and can email you when attributes cross thresholds. The fastest setup is a one-line /etc/smartd.conf:

DEVICESCAN -a -m [email protected]

This scans every drive at startup and mails that address on trouble. For a visual layer, the Scrutiny drive-health dashboard puts the same SMART data behind a web UI — the continuous-monitoring lane to this guide's manual-check lane, never a rival. And if the server feels slow but the disk checks out, the next diagnostic in the family is checking RAM usage on Linux — memory pressure mimics disk trouble surprisingly well.

Sources

The commands and definitions above were verified against these sources, all fetched for this guide: the smartctl(8) man page (flag definitions, -H semantics, -a expansions, self-test behavior); the smartd.conf(5) man page (the DEVICESCAN one-liner); the nvme-smart-log(1) man pages on Arch and openSUSE (the 3.0 deprecation of the old command form); the libnvme nvme_smart_log(2) man page (spec-language field definitions); Backblaze's "Hard Drive S.M.A.R.T. Stats" (the five predictive attributes and the SMART 187 zero rule); Hard Disk Sentinel's S.M.A.R.T. attribute list (attribute definitions); Wikipedia's S.M.A.R.T. article (the 39x failure-odds figure for attribute 198); AlexHost's smartctl utility guide (install commands, the -a expansion check, NVMe version guidance); Liquid Web's smartctl help doc (install, the PASSED caveat); linuxconfig.org (install commands); the tiespecialistas NVMe health guide (nvme-cli 3.0 syntax, field interpretation, the abrupt-failure caveat); FOSS Linux's smartmontools guide (the report examples, the VMware "SMART support is: Unavailable" capture); the Proxmox community forum (virtual disks expose no SMART data to guests); and tech-insider.org (the sudo requirement).

Frequently Asked Questions

Does smartctl -H PASSED mean my drive is healthy?

No — and this is the single most misunderstood line in disk health. PASSED only means no manufacturer failure threshold has been crossed yet. The man page defines -H as a boolean check: FAILED means the drive has already failed or is predicting its own failure within the next 24 hours. A drive can sit at PASSED with a climbing reallocated-sector count, which is why the attributes table is the real audit.

Why does smartctl say "SMART support is: Unavailable" on my VPS?

Because the guest OS sees a virtual disk, not the physical drive. Virtualization layers (KVM/virtio, VMware, Hyper-V) do not pass S.M.A.R.T. data through to guests — the smartctl man page and multiple host-community sources confirm this. On a VPS, drive health is your provider's job; yours is capacity, latency, and tested backups.

Should I use smartctl or nvme smart-log for an NVMe SSD?

Both read the same health log, so use whichever you have. smartctl -a /dev/nvme0 works if smartmontools 7.x is installed; nvme log smart /dev/nvme0 (nvme-cli 3.0+) exposes the native NVMe fields — Critical Warning, Percentage Used, Available Spare — with cleaner labels. If you only install one tool on an NVMe server, make it nvme-cli.

What is a dangerous Percentage Used value on an NVMe SSD?

There is no red line, because Percentage Used measures endurance consumed, not failure probability. The NVMe spec defines it as a vendor-specific estimate of NVM life used — 100 means the rated endurance is consumed but "may not indicate an NVM subsystem failure," and values can exceed 100. Use it as a planning gauge: climbing fast toward 100 means budget a replacement; combine it with Critical Warning and Media Errors for the actual health verdict.

Should I run smartctl -t long on a drive I suspect is failing?

Copy the data off first, then test. The man page warns that a running self-test can degrade drive performance, and a long test hammers the whole surface of a drive that may already be marginal. The safe order is always: back up, then diagnose. A short test (under ten minutes) is the reasonable middle ground when you need a quick signal without the stress.