How S.M.A.R.T. actually works: a mental model for operators

S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology) is not a tool, an agent, or a daemon. It is firmware-level self-instrumentation embedded in every modern HDD, SSD, and NVMe drive. The drive itself continuously monitors its internal health and reports what it finds. The smartctl utility from smartmontools is simply a reader: it queries the drive and prints what the firmware already knows. It has no independent intelligence about drive health.

Every SMART-based monitoring decision, every threshold, and every false alarm traces back to a single question: what does the drive firmware actually track, and how does it choose to expose it? The firmware tracks error correction outcomes, sector integrity, NAND wear, mechanical behavior, temperature, and power events. But the way it surfaces that data depends entirely on the drive interface, and the three interfaces in production today (ATA/SATA, SAS/SCSI, and NVMe) use three fundamentally different data models that are not interchangeable.

What it is and why it matters

Inside every drive, firmware runs continuously and tracks a consistent set of internal state regardless of interface:

• Error correction: Every read passes through ECC (Error Correction Code). The firmware counts how many reads required correction and how many failed correction entirely.
• Sector health: The firmware maintains a defect list (bad blocks already remapped to spare sectors), a pending list (suspect sectors awaiting rewrite to confirm status), and a spare pool (reserve capacity for future remapping).
• Wear state (SSD/NVMe): NAND flash cells have finite program/erase cycles. The controller tracks per-block wear, manages wear leveling, handles garbage collection, and monitors write amplification.
• Mechanical state (HDD): Actuator positioning accuracy, head flying height, spindle motor behavior, and vibration events.
• Environmental conditions: Internal temperature, power cycle count, power-on hours, unsafe shutdown count.
• Error logs: A circular buffer of recent I/O errors with details including LBA, error type, and timestamp within the power cycle.
• Self-test history: Results of offline surface scans.

The firmware knows all of this at all times. What you can see depends on the interface. The boundary between what the drive knows and what it reports is the single most important concept in SMART monitoring. Drives can and do fail in ways the firmware detects but does not surface in SMART attributes. Google’s 2007 study found that 36% of failed drives had zero SMART attribute warnings beforehand. SMART monitoring is necessary but not sufficient: you still need redundancy, checksums, and backups.

How it works

The firmware always monitors internally, but it exposes data through three incompatible external models. Understanding which model your drive uses determines how you interpret every value.

flowchart TD
    FW["Drive firmware
(always self-monitoring)"]
    FW --> ATA["ATA SMART attributes
VALUE / THRESH / RAW
Pre-fail vs Old-age
(non-standardized IDs)"]
    FW --> SCSI["SCSI log pages
Temperature, PHY errors
start-stop cycles
(structured format)"]
    FW --> NVMe["NVMe health log 0x02
Available Spare, Percentage Used
Critical Warning bits
(spec-defined fields)"]
    ATA --> CTL["smartctl"]
    SCSI --> CTL
    NVMe --> CTL
    CTL --> OPS["Monitoring system / operator"]

ATA attributes: the non-standard standard

For SATA drives, smartctl -A /dev/sdX prints a table of vendor-specific SMART attributes. Each row has these columns:

The failure condition is simple: when VALUE is less than or equal to THRESH for any Pre-fail attribute, the drive reports FAILED overall. But vendors set generous thresholds to minimize warranty claims. A drive can have dozens of reallocated sectors, rising pending sectors, and degraded performance, and still report PASSED.

The TYPE field divides attributes into two categories:

• Pre-fail: Attributes that can predict imminent failure. Only these trigger the PASSED/FAILED assessment. Reallocated Sector Count (ID 5), Current Pending Sector (ID 197), and Offline Uncorrectable (ID 198) are typical Pre-fail attributes.
• Old_age: Attributes that track normal wear and lifecycle (Power-On Hours, temperature, power cycles). These never trigger FAILED regardless of their value.

The fundamental problem with ATA SMART is that attribute IDs are not standardized. The ATA-3 draft in 1997 contained attribute descriptions, but they were removed before final adoption. Each manufacturer defines its own attribute IDs, meanings, and raw value encoding. ID 198 is “Offline_Uncorrectable” on most drives but “Offline_Seek_Performance” on some WD models. Smartmontools handles this with a vendor-specific preset database (drivedb.h), but the raw values still require vendor-aware interpretation. Seagate drives are the most notorious example: Raw Read Error Rate (ID 1) and Seek Error Rate (ID 7) raw values routinely show in the billions on perfectly healthy drives because Seagate packs total operation counts and error counts into sub-fields of the 48-bit raw value. Only the normalized VALUE is meaningful for Seagate drives.

NVMe: the standardized health log

NVMe drives do away with vendor-specific attribute IDs entirely. Instead of a table of numbered attributes, NVMe uses a structured log page (Log Page 02h, the SMART/Health Information Log) where every field is defined by the NVMe specification. The key fields:

• Critical Warning: A bitmask byte where each bit flags a specific critical condition (spare below threshold, temperature critical, reliability degraded, read-only mode, volatile memory backup failed).
• Composite Temperature: Current internal temperature reported by the controller, used for thermal throttling decisions.
• Available Spare: Percentage of spare NAND capacity remaining for bad-block replacement.
• Available Spare Threshold: Vendor-set threshold (typically 10%) below which Critical Warning bit 0 fires.
• Percentage Used: Vendor-calculated estimate of endurance consumed, 0-255%. Values above 100% indicate the drive has exceeded its rated endurance.
• Data Units Written/Read: Cumulative host I/O volume, reported in thousands of 512-byte units.
• Media and Data Integrity Errors: Count of uncorrectable data errors from the NAND media.
• Unsafe Shutdowns: Count of unexpected power losses.

This standardization means monitoring logic for NVMe drives does not need vendor-specific interpretation. Every field means the same thing on every NVMe drive. smartctl -A /dev/nvme0n1 prints these fields directly, without the ID/VALUE/THRESH/RAW abstraction.

SAS/SCSI: log pages, not attributes

SAS and SCSI drives do not have ATA-like SMART attributes at all. smartctl -A on SCSI devices produces structured output from log pages (read/write/verify error counters, temperature, grown defect list length, start-stop cycle counter), not an attribute table. The output format is completely different from ATA. Many operators expect to see “Reallocated_Sector_Ct” on SAS drives and find nothing.

Transport health on SAS drives uses SAS PHY error counters (invalid dword count, running disparity error count, loss of dword sync count, PHY reset problem count), not the UDMA CRC Error Count (ATA ID 199) that SATA drives use. smartctl -l sasphy /dev/sdX reads SAS PHY error counters.

Where it shows up in production

The mental model shifts depending on how drives are deployed:

• Behind hardware RAID controllers: RAID controllers (LSI/Broadcom MegaRAID, HP Smart Array, Adaptec) often abstract or mask SMART data. You must use controller-specific passthrough (-d megaraid,N, -d cciss,N, -d sat+megaraid,N) to reach individual drives. Without passthrough, drives can fail silently with no alert.
• USB-attached drives: USB-to-SATA bridges may not pass SMART commands. Many bridges do not properly support SAT (SCSI/ATA Translation) in UAS mode. smartctl may report “Unknown” or fail entirely. Use -d sat or bridge-specific flags like -d usbcypress.
• Virtual machines: Hypervisors typically do not pass through SMART data. Monitoring must happen on the hypervisor host, not inside the VM. If you see SMART data inside a cloud VM, it is emulated and unreliable.
• HDD vs SSD vs NVMe: Fundamentally different attribute sets and failure modes. HDDs expose mechanical/media attributes via ATA SMART. SSDs expose wear/endurance attributes that differ by vendor. NVMe uses the standardized health log described above. You cannot apply ATA alerting logic to NVMe drives or vice versa.

Common misuses

Treating PASSED as health. The PASSED/FAILED assessment only checks whether any Pre-fail attribute has crossed its vendor-defined threshold. Vendors set thresholds high to minimize warranty claims. A drive with hundreds of pending sectors and dozens of reallocated sectors can still report PASSED. Never monitor only the health assessment. Always track individual attributes.

Alerting on raw values without vendor awareness. The RAW_VALUE column is the most misused field in SMART monitoring. Seagate’s raw value encoding for ID 1 and ID 7 produces values in the billions on healthy drives. Naive monitoring that alerts on high raw values will generate constant false alarms. The normalized VALUE is the only cross-vendor comparable metric, and even its starting scale varies (some vendors use 100, others 200 or 253). Always key alert logic on the decoded attribute name, not the raw ID, because vendors reuse IDs for different purposes.

Checking absolute values instead of rate of change. A drive with 50 reallocated sectors accumulated over 5 years is stable. A drive with 5 reallocated sectors gained in the last week is actively dying. Most monitoring checks absolute values only, missing the acceleration signal that distinguishes historical damage from active failure. Rate-of-change tracking is the single most important improvement most teams can make to their SMART monitoring.

Not running extended self-tests. Drives do not run self-tests automatically. Without scheduled extended self-tests (smartctl -t long /dev/sdX), latent bad sectors hide until production I/O hits them, at which point you get an I/O error in production instead of a self-test warning during a maintenance window.

Paging on lifetime counters at first deployment. When SMART monitoring is first deployed on an existing fleet, cumulative counters (Offline Uncorrectable, NVMe Media Errors, Power-On Hours, Unsafe Shutdowns) will have non-zero historical values. The monitoring system must establish a baseline on first scrape and alert only on growth from that baseline, not on absolute values. Paging on lifetime values at first deployment floods operators with false alarms from every drive with any history.

Signals to watch in production

How Netdata helps

Netdata’s SMART monitoring applies the concepts above:

• Per-second collection of SMART attributes enables rate-of-change tracking, which distinguishes historical damage from active failure better than point-in-time threshold checks.
• Correlating ATA media attributes (IDs 5, 197, 198) with host-level I/O latency from iostat and /proc/diskstats distinguishes drive-level degradation (high iowait, low CPU, rising pending sectors) from software issues (high CPU, normal disk latency).
• Separating transport errors from media errors by correlating UDMA CRC count (ID 199) against reallocated/pending/uncorrectable counts prevents the common mistake of replacing drives when the cable is the problem.
• NVMe alerting centered on Available Spare, Percentage Used, and Critical Warning bits, rather than treating NVMe like SATA with different attribute names.
• Anomaly detection on SMART trends catches gradual degradation patterns (slow reallocated sector growth, declining Available Spare) before they trip static thresholds.
• Automatic baseline establishment on first observation handles fleet-wide deployment without flooding operators with historical counter values.

Related guides

• smartctl disk monitoring checklist: the SMART signals every server needs
• SMART monitoring maturity model: from survival to expert
• Reallocated_Sector_Ct rising: the drive is burning through its spare pool
• Current_Pending_Sector non-zero: unreadable sectors and I/O latency spikes
• Offline_Uncorrectable climbing: permanent data loss at the media level
• Reallocated_Event_Count vs Reallocated_Sector_Ct: reading both together
• Raw_Read_Error_Rate looks enormous: the Seagate false alarm explained
• The zombie drive: bad sectors, read retries, and high iowait with idle CPU
• SMART says PASSED but the drive is failing: why the health check lies
• SMART overall-health self-assessment: FAILED is the drive’s own death notice
• Self-test completed: read failure — a bad sector found by proactive scanning
• Scheduling SMART self-tests: short weekly, extended monthly