Pablo #2: 98% healthy, apparently

Oct 02, 2026· 6 min read

Part 2 of the Pablo saga, in five parts. Previously: Pablo #1. Next: Pablo #3.

July-August 2026 - When the numbers stopped making sense.

By now I had a problem. Windows had logged bad-block errors. The HP BIOS had reported an imminent drive failure. smartctl had returned a failed health assessment.

And yet, CrystalDiskInfo was showing 98% health.

If you put those findings next to each other, you'd be forgiven for thinking at least one of the tools was lying. Unfortunately, the explanation was more complicated than that.

Enter smartctl

I'd been collecting SMART data through MonSMART, but I wanted the full picture. That led me to smartctl, from the smartmontools project - less a dashboard, more the raw feed: attributes, error logs, self-test history, power-on hours, temperature, interface stats.

smartctl -a /dev/sda

smartctl -x /dev/sda

The second one asks for everything. Some of it was straightforward, some cryptic - and some attributes showed up as unknown, because the drive identified itself as a CONSISTENT S6 SSD 256GB (firmware V0422A0) that wasn't in smartmontools' database. I could see the numbers without knowing exactly how the manufacturer encoded them, which was a useful limitation to understand early: I wasn't going to invent meanings for attributes just because their raw values looked interesting.

The raw counters

At one stage, the important ones looked like this:

Reallocated Sectors:       41
Current Pending Sectors:   41
Offline Uncorrectable:     32
Reallocation Events:       32
UDMA CRC Errors:            1

These aren't interchangeable:

Sector counters describe storage errors; reallocation events are another counter; CRC errors point at the SATA interface, not the NAND - a cable-or-controller smell rather than dying flash. Conversely, climbing sector counters plus repeated bad blocks plus a firmware failure warning make the cable theory very hard to sustain.

The overall picture mattered more than any single attribute. And the picture wasn't getting prettier.

Why 98% meant almost nothing

CrystalDiskInfo showed the drive as GOOD, 98% remaining - while the BIOS warned of imminent failure and smartctl reported FAILED. The key: the 98% is primarily an endurance estimate. It answers one question:

• Endurance: what does the drive report about remaining rated life?
• SMART attributes: what counters is the firmware exposing?
• Overall SMART status: has a firmware threshold tripped?
• OS errors: what has Windows actually hit while reading?

These overlap, but none replaces the others. An SSD can have nearly its full rated life ahead of it while failing in ways endurance was never designed to measure. A green indicator is useful interpreted correctly; treated as proof that everything is fine, it's dangerous.

There was a second trap inside the attributes themselves. SMART carries normalized values (manufacturer-scaled, thresholds apply here) alongside raw values (a separate encoding per attribute and firmware). Many of Pablo's normalized values sat at 100 against a threshold of 50 while raw sector counters climbed. Reading raw 41 against threshold 50 as "still fine" would have been wrong - different scales. But ignoring the raw climb because the normalized value looked healthy would have been worse. Without the vendor spec, the honest read was: serious reported problems, moving counters, real OS errors. Enough to justify caution.

The failure warning is not a schedule

SMART overall-health self-assessment test result: FAILED!
Drive failure expected in less than 24 hours.

Frightening wording, especially on the computer you use every day. But SMART warnings aren't countdowns - firmware flags a condition it considers serious, and the drive might last days or weeks past it. Mine kept booting Windows far longer than that message implied.

That didn't make the warning meaningless. The sensible response to an imminent-failure warning is to protect the data, not to test how long the drive can survive. That became one of the central lessons of the whole saga.

From snapshots to history

A single SMART report is one moment in time. It can't show velocity - and velocity was the whole story: 40 to 41 to 43, climbing while the laptop kept working. Manually diffing pages of smartctl -x output every evening gets old fast, so the question changed from "is the drive healthy?" to "what changed since the last scan?"

That second question is what MonSMART grew into answering. It had existed before Pablo - one of my small TinyScripts utilities for checking drive health - but the failure changed what I needed it to be: preserve readings, highlight deltas, shut up when there's nothing new. Not a smartctl replacement; a glanceable layer over it. A failed status tells you there's a problem. A comparison tells you whether it's getting worse.

There was something slightly absurd about developing a drive-monitoring tool and then discovering the monitored drive was dying. You start with a utility meant to say "looks okay," and end up relying on it to understand a real failure on your own machine. At least I had a way to record what was happening.

One thing I kept straight throughout: monitoring is not repair. MonSMART could collect, preserve, and highlight - it couldn't fix NAND, and it was never going to talk me into trusting an unreliable drive just because I could now watch it deteriorate in high definition.

By this stage the evidence was cumulative - bad blocks, BIOS warning, FAILED assessment, climbing counters - and the diagnosis no longer depended on any single magic number. What it depended on now was getting the data off before the numbers stopped mattering entirely.