# What SMART data isn't telling you: which attributes predict drive failure (Problem Specifics 1/5) > Why a drive's SMART status can say PASSED right up to failure, which attributes predict it (5, 187, 188, 197 and 198), and how to trend them against peers. - URL: https://blog.asama.ai/blog/issue-06-asama-what-smart-data-isnt-telling-you/ - Author: Jain Johny - Published: 2025-12-28 - Tags: Fleet problems, Field notes SMART (Self-Monitoring, Analysis and Reporting Technology) is the health data a drive reports about itself, and it misses many failures. In [Google's 2007 study](https://www.usenix.org/conference/fast-07/failure-trends-large-disk-drive-population) of more than 100,000 drives, over 36% of failed drives had zero counts on every SMART variable the study tracked except temperature, and in a [2016 analysis](https://www.backblaze.com/blog/what-smart-stats-indicate-hard-drive-failures/) Backblaze found that 23.3% of its failed drives showed no warning in any of the five SMART attributes it used to predict failure. The drive's own PASSED or FAILED verdict catches far fewer: by [manufacturers' own estimate](https://jmlr.org/papers/v6/murray05a.html), reported in a 2005 study, the threshold algorithm detects 3 to 10% of failures. SMART has been the standard interface for disk health data since the mid-1990s. SATA drives report it as a table of numbered attributes, NVMe drives as a SMART/Health Information log, and SAS drives through SCSI log pages. Every monitoring tool reads them. Every infrastructure team has [a dashboard that turns SMART data into a simple status](https://blog.asama.ai/blog/issue-01-asama-uptime-is-not-reliability): healthy or at risk. That dashboard is lying to you. Not maliciously, but structurally. Each SATA attribute carries a raw value and a normalised value, and the drive's firmware converts one into the other. The drive reports failing health when a pre-failure attribute's normalised value falls to the manufacturer's threshold, and manufacturers set those thresholds conservatively, to keep false alarms to around one drive in 1,000 a year. A drive can log its first reallocated or pending sectors, the counts that best predict failure, while every normalised value is still far above its threshold. > The warning is the first non-zero raw count, not the threshold crossing. In Google's study, drives were over 14 times more likely to fail within 60 days of their first reallocation than drives without one. --- ## The SMART attributes worth reading | ID | smartctl name | What it counts | How to read it | | :--- | :--- | :--- | :--- | | 5 | Reallocated_Sector_Ct | Sectors remapped to spares after errors | Any non-zero raw value, then how fast it grows | | 187 | Reported_Uncorrect | Errors the drive's ECC could not recover | Non-zero is a strong signal | | 188 | Command_Timeout | Commands the drive did not complete in time | A rising count; check cabling, backplane and HBA too. On many Seagate drives the raw value packs three 16-bit counters, so read smartctl's decoded value, not the raw integer | | 197 | Current_Pending_Sector | Unstable sectors waiting to be remapped | Non-zero; it falls when a sector is rewritten, so read it with attribute 5 | | 198 | Offline_Uncorrectable | Sectors the drive's offline scan could not read | Non-zero; not every manufacturer reports both 197 and 198 | | 199 | UDMA_CRC_Error_Count | Errors on the link between drive and controller | A rising count usually points at a cable or backplane, not the media | | 1, 195 | Raw_Read_Error_Rate, Hardware_ECC_Recovered | Vendor-specific error rates | Never compare raw values across vendors: on Seagate Exos drives, attribute 1 packs an error count and an operation count into one raw value | | 177, 233 | Wear_Leveling_Count (Samsung), Media_Wearout_Indicator (Intel) | SSD wear, in each vendor's own units | Read the normalised value, which counts down from 100 as rated endurance is used (Intel leaves the raw value at 0), and trend it against identical drives | Backblaze used the first five as its failure predictors: 76.7% of its failed drives had at least one of them above zero, against 4.2% of drives still in service. Healthy drives far outnumber failing ones, so that 4.2% is a lot of drives: a first non-zero count means look closer and start trending, not replace the drive. On NVMe drives, the SMART/Health Information log takes the place of the attribute table. Watch media and data integrity errors, available spare against its threshold, and percentage used, a vendor estimate of life consumed that can pass 100 without the drive failing. The critical warning byte in that log is what `smartctl -H` reports on NVMe. On SAS drives, `smartctl -x` prints the elements in the grown defect list and an error counter log for reads, writes and verifies. Read a growing defect list and any total uncorrected errors the way you read attributes 5 and 187. There, `-H` prints SMART Health Status: OK rather than PASSED. Two habits make these numbers useful. Read raw values for the error and sector counts, not normalised ones, and watch the change: the first non-zero count and how fast it grows say more than any absolute number. And compare like with like, with a baseline for each drive model and [firmware revision](https://blog.asama.ai/blog/issue-02-asama-config-drift-is-the-silent-killer), because the same raw value can mean different things on different drives. ## Reading SMART yourself ```bash smartctl -H /dev/sda # the drive's own verdict: PASSED on SATA until a threshold check fails smartctl -x /dev/sda # SATA: VALUE, WORST, THRESH and RAW_VALUE for every attribute, plus the error logs smartctl -a /dev/nvme0 # NVMe: the SMART/Health Information log nvme smart-log /dev/nvme0 # the same log through nvme-cli ``` smartctl decodes vendor raw formats from its drive database, so run `update-smart-drivedb` before you trust raw values on new models. For Prometheus, the community's [smartctl_exporter](https://github.com/prometheus-community/smartctl_exporter) exposes the same data as metrics. --- ## Baselines and peers, not thresholds Better storage monitoring reads all SMART attributes at onboarding, not just the ones that map to vendor thresholds. It builds a baseline for each disk model and firmware version. It compares each disk against its own historical trajectory and against [a peer cohort of identical hardware](https://blog.asama.ai/blog/clustering-for-infrastructure-observability) under similar workloads. Google's own conclusion was that SMART data alone is unlikely to predict failures of individual drives, so pair it with what the host sees: I/O latency against the drive's peers, and errors and link resets in the kernel log. A disk that is "still healthy" by every vendor definition but is clearly trending worse than every other disk in its cohort can be flagged weeks before it fails, with enough lead time to schedule a replacement, migrate workloads, and avoid P99 latency degradation and data risk. --- ## Food for thought > Does your current storage monitoring compare disks against their own historical baseline and peer cohort, or does it wait for a vendor threshold to tell you something has already gone wrong? **Update, October 2026.** Asama's fleet visibility, which reads drives through SMART and the NVMe health log, is generally available. Detection built on it, which compares each node against its own baseline and against its peers, has been validated; investigation and remediation are expanding. Asama's fleet observations put about 65 servers in every 1,000 in a silently degraded state that no threshold sees. To see which of your drives are trending worse than their peers, book a live comparison against your stack at [asama.ai](https://www.asama.ai), or write to contactus@asama.ai.