What smartctl and smartd can and cannot tell you about a failing drive

The answer. smartctl and smartd read what the drive's firmware chooses to publish, and a clean reading is weak evidence of health. A PASSED status is the absence of a boolean failing flag, which the manual ties to a drive that has already failed or predicts failure within 24 hours; it is not a statement that nothing is wrong. In the field data a large minority of failures came with nothing to read: 23.3% of Backblaze's failed drives (from 76.7% having at least one flag) and over 56% of Google's failed drives against its four strongest signals.

What the tools do well. When a flag is raised it carries a lot of information: Backblaze's reallocated-sector, pending-sector and uncorrectable-error attributes were non-zero on 42.2% to 43.5% of failed drives one day before failure but on 0.5% to 1.1% of working drives, ratios of about 38 to 87 times (derived), and 4.2% of working drives had any of the five against 76.7% of failed ones. smartd turns this into automation without extra code: a one-line DEVICESCAN configuration expands to the health check, usage-attribute check, error log, self-test log and the 197 and 198 counters, polled every 30 minutes, with e-mail reminders that thin out over days. smartctl's exit status separates eight signals, so a script can tell 'drive says failing' (8) from 'could not read the drive' (2 or 4) from 'an attribute failed in the past' (32).

Thresholds are the weakest part. A threshold is a number the manufacturer set, applied to a normalized value the firmware computed, and the smartctl manual states that smartctl only reports them. A pre-fail attribute at its threshold means failure is imminent, but a pre-fail attribute with a bad raw count and a normalized value still above the threshold stays quiet on the health check. This is why operators using raw counts above zero (Backblaze) catch drives that a threshold-only check would still call fine, and also why they get false positives: 4.2% of working drives tripped one of the five flags, and the Backblaze post says a single non-zero value, such as two remapped sectors, can mean little on its own.

Blind spots seen in the sources. First, the ceiling: Google concluded that models built on SMART alone are unlikely to predict individual failures, because over 56% of failures had none of the four strong signals and over 36% had none on any variable except temperature. Second, coverage by vendor: the Backblaze slide says attributes 187, 188 and 198 come from Seagate drives only, so a fleet that mixes vendors cannot apply the same five-flag rule to all of them. Third, path: the smartctl manual warns that a RAID controller or USB bridge can leave the health status unknown, and the smartd manual notes that a polling interval above 60 minutes can skip a scheduled self-test slot. Fourth, timing: a 1,800 s poll cannot see a short event that left no log entry. Fifth, rates versus counts: Backblaze describes SMART 189 as 47.0% against 16.4% (failed against working) and says the signal may lie in clusters of errors over a short time, not in the cumulative count, which a simple greater-than-zero rule would miss.

What to do with this, within the evidence. Use smartd for what it is good at, a cheap standing watch for health status, pending and uncorrectable sectors, error and self-test logs. Treat a non-zero 197 or 198 as a data-integrity warning (the manual says it means some data on the disk is currently unreadable), and treat a clean report as only that. Do not read either fleet as a detection rate for current drives: neither study measures how often an alert preceded a failure by enough time to act, the two fleets used different definitions of failure, and none of the sources opened here covers SSD or NVMe monitoring in numbers.