smartctl and Bad Sectors: What It Really Tells You, and the 23% It Misses

Search for this topic and Google will suggest "smartctl fix bad sectors" to you. That suggestion describes something the tool does not do, and the gap between what people expect and what SMART actually provides is where data gets lost.

smartctl reports, it does not repair

The documentation leaves no room for interpretation: smartctl "does not calculate any of the Attribute values, thresholds, or types, it merely reports them from the SMART data on the device."

It is a monitoring and reporting utility. There is no flag that repairs a sector, because repairing is not something a diagnostic tool does. When a drive reallocates a bad sector, the firmware does it, silently, using a spare from its reserve pool.

This matters practically. Any utility advertising that it "fixes" bad sectors is doing one of two things: writing over them, which permanently destroys whatever was in them, or forcing the firmware's hand into reallocation. Neither recovers your file. If the data still matters, writing to the drive is the last thing you want.

The five attributes worth reading

Backblaze runs one of the largest published datasets on drive failure, and monitors five SMART attributes for prediction:

Their published comparison: 76.7% of failed drives had at least one of these above zero, against 4.2% of operational drives. That separation is what makes them worth checking.

The two most commonly misread are 197 and 5, and the difference between them is worth understanding.

197, Current Pending Sector Count, is the provisional list. These are sectors the drive had trouble reading and has put on probation. They are not yet condemned. If a later read succeeds, the count can go back down.

5, Reallocated Sectors Count, is the permanent record. These are sectors the drive gave up on and swapped for spares. This number only goes up.

So a non-zero 197 is the earlier warning, and the one worth acting on, because it says the drive is currently struggling to read something. That something may well be your file.

How to read the output without misreading it

Three commands cover the practical ground:

smartctl -H /dev/sda      # overall health status
smartctl -A /dev/sda      # the attribute table
smartctl -l selftest /dev/sda   # results of past self-tests

On -H, the documented meaning of a failure is specific and urgent: "either that the device has already failed, or that it is predicting its own failure within the next 24 hours." Twenty-four hours is not a maintenance window. It means copy what matters now.

On -A, each attribute carries a Raw value, a Normalized value and a Threshold. The documented rule is that if the normalized value is less than or equal to the threshold, the attribute has failed. People routinely read the raw column and panic, or read it and relax, without checking it against the threshold. The raw value alone does not tell you whether an attribute has failed.

To run the tests themselves:

smartctl -t short /dev/sda    # usually under ten minutes
smartctl -t long /dev/sda     # tens of minutes, more thorough

The short test checks electrical and mechanical performance along with read performance. The extended test is the longer, more thorough version. In both cases the command launches the test and returns; you read the outcome afterwards with -l selftest, which shows the type and final status of each of the most recent self-tests.

The number nobody quotes: 23.3%

Here is the part that should change how you act on a clean report.

By Backblaze's own figures, if 76.7% of failed drives showed a warning, then 23.3% of failed drives showed none at all. Close to one failure in four arrives with SMART reporting nothing wrong.

SMART is a useful early warning that is silent about a quarter of the time. It is evidence of a problem when it speaks, and not evidence of health when it does not. A passing check means nothing bad has been detected yet. It does not mean the drive is fine, and it is not a substitute for having a second copy.

What to do when the numbers are bad

The order matters, and the first step is the one people skip.

Stop writing to the drive. Every write is a chance to overwrite something recoverable and more work for a mechanism that is already struggling.

Image before you investigate. Work from a sector-level copy, not the failing drive. Repeated read attempts on a drive with pending sectors put stress exactly where it is already weak, and each retry is a chance for a marginal sector to become an unreadable one. We cover the process in cloning a failing drive with ddrescue.

Then recover from the image. Once you have a copy, you can retry as often as you like without risking the original.

The short version

smartctl tells you what the drive reports about itself. It never repairs anything, so treat "fix bad sectors" as a description of something else. Read attribute 197 as the early warning and 5 as the permanent record, and compare normalized values against thresholds rather than reading raw numbers alone. A failing -H gives you a documented 24-hour horizon. And a clean report is not a clean bill of health, because roughly one failure in four never showed up in these statistics at all.

Command behaviour and attribute semantics are taken from the smartctl documentation; the failure-correlation figures (76.7%, 4.2%, 23.3%) are Backblaze's published statistics from their own fleet. Figures describe their drive population and are not a prediction for any individual drive. Commercial links carry the rel="sponsored nofollow" attribute; an affiliate commission may apply at no extra cost to you.