Reallocated sectors: is your drive dying or just scarred?

Two drives on the same HBA, same evening, same test. Here are the SMART lines that matter, before I touched either of them:

sde  (Seagate 10TB)   Reallocated_Sector_Ct = 344   Current_Pending = 0
sdd  (Toshiba 8TB)    Reallocated_Sector_Ct = 0     Current_Pending = 160

One of these drives is dying. Pick.

If you picked sde — 344 reallocated sectors, a four-thousand-count of reported-uncorrectable errors sitting in its history — you read SMART the way almost everyone reads it, and you picked wrong. sde is fine. It's scarred, but it's fine. The one that's dying is sdd, the one with a perfect zero in attribute 5.

The raw Reallocated_Sector_Ct is one of the most-quoted, least-useful numbers in a SMART report. Staring at it tells you almost nothing about whether a drive is going to survive the year. What tells you is whether the defect counters move — and move correctly — when you force the firmware to make a decision it's been putting off.

The static number is a receipt, not a diagnosis#

Reallocated_Sector_Ct is a count of sectors the firmware has already given up on and remapped to spare area. Past tense. It's a receipt for damage the drive has already dealt with. A high number means the drive hit a rough patch at some point and handled it. That's the part people miss: reallocation is the drive working, not the drive failing.

The number that actually describes the drive's current predicament is Current_Pending_Sector, attribute 197. A pending sector is one that failed a read and is now unstable — the firmware can't correct it with ECC, but it also won't retire it yet, because it doesn't have enough information. It's holding the sector in a queue, waiting for something.

What it's waiting for is a write.

Here's the mechanism, because it's the whole point. When you read a bad sector, the drive can only shrug: maybe the data was written wrong, maybe the platter is bad, it can't tell the difference from a read. So it files the sector under "pending" and moves on. The disambiguation only happens on the next write to that LBA:

• The rewrite succeeds and reads back clean → the sector was fine, the data was just corrupt. Firmware clears it from pending. Attribute 5 does not move.
• The rewrite fails → the platter is bad. Firmware maps in a spare, retires the sector, and now attribute 5 increments.

One widely-cited SMART writeup puts it better than I can, describing a pending sector — attribute 197: "I couldn't read this even though I tried hard... we'll only know when we next write to it." The write is the disambiguator. Until you write, the drive is genuinely undecided, and so is its SMART table. A pending count can sit frozen for years — the drive never revisits those LBAs on its own, so the question never gets asked.

Which means a SMART report you pull at rest is a snapshot of decisions the drive has happened to make so far. If you want to know whether the defect-management system still works, you have to make it work. You have to force every weak sector on the platter through that remap-or-clear fork and watch which way it falls.

badblocks -w is the forcing function#

badblocks -wsv -b 4096 -t 0x00 /dev/sde

-w is destructive write mode: it writes a pattern to every block, then reads it back to verify. -s shows progress, -v is verbose, -b 4096 matches the 4K physical sector on an Advanced Format drive, -t 0x00 writes a single zero pattern. On a 10TB drive this is a ~26-hour commitment and it obliterates everything on the disk, so this is a triage bench tool, not something you point at a live pool.

But it does exactly the one thing a static SMART read can't: it drags every sector — good, weak, and pending — through an actual write. Every pending sector gets its answer. The firmware has nowhere left to defer to. Whatever the drive's defect management is going to do, it does it in the next day, in front of you, and the counters move while you watch.

So I ran it on both. Same command, same night.

Drive A: the scarred survivor#

sde is a Seagate ST10000DM0004, 10TB, ~24,745 power-on hours. It has a history, and the history is ugly.

It came out of a cheap USB enclosure — one of those external-drive shells that turns out to be a slow-motion drive murderer. Bad power delivery, a flaky bridge controller, no vibration damping. That enclosure had already killed several drives outright, which makes it the most productive piece of hardware in this story. This one it only wounded: 344 reallocated sectors and 4003 reported-uncorrectable errors, accumulated during the enclosure years. I shucked it, put it on the HBA, and the bleeding stopped. No new errors for months. The scars were real, but they were old.

The write pass confirmed it. Before and after:

                          before   after
Reallocated_Sector_Ct       344     352    (+8)
Current_Pending_Sector        0       0
Offline_Uncorrectable         0       0
Reported_Uncorrect         4003    4003    (frozen)
Command_Timeout              35      35    (frozen)

badblocks: Pass completed, 0 bad blocks found. (0/0/0 errors)

Read that again, because every number is doing work. The reallocated count went up by eight — the write pass found eight weak sectors, tried to rewrite them, the rewrites failed, and the firmware retired all eight to spare. That's not decay. That's the defect-management system executing correctly: it found bad sectors, it retired them, and it kept a clean bill everywhere else. Pending stayed at zero. Offline-uncorrectable stayed at zero. And badblocks — after writing and reading back all 10TB — found zero bad blocks, because every weak sector it hit got remapped out from under it before the verify pass came around.

The old scars — 4003 reported-uncorrect, 35 command-timeouts — didn't move at all. Frozen. They're a fossil record of the enclosure era, and a fossil doesn't grow. A drive that's actively failing doesn't leave its damage counters frozen; it adds to them.

Verdict: worn, honest about it, and stable. If drives came with references, I'd write this one a good one. I'd store data on it tomorrow.

Drive B: the pristine-looking corpse#

sdd is a Toshiba MG06ACA800E, 8TB, 54,631 power-on hours — 6.2 years, and it looked cleaner than the Seagate. Reallocated_Sector_Ct: 0. Not a single retired sector in six years. If the raw number were the diagnosis, this is the drive you'd trust.

It had 160 pending sectors and 126 offline-uncorrectable going in, which a lot of people wave away — pending sectors "might clear on a write," the folklore goes. So I gave it the exact same write pass and watched what the firmware did with 160 sectors it had been sitting on.

It did nothing.

                          before   after
Reallocated_Sector_Ct         0       0    (never moved)
Current_Pending_Sector      160     224    (+64, climbing)
Offline_Uncorrectable       126     ...

badblocks: Pass completed, 58 bad blocks found. (58/0/0 errors)

kernel: critical medium error, dev sdd, sector 817267128
        Sense Key : Medium Error [current]
        Add. Sense: Unrecovered read error

This is the tell, and it's the whole article in three numbers. Reallocated stuck at zero — through a full-platter write pass, the firmware retired not one sector to spare. Meanwhile pending climbed from 160 to 224. Writing a pending sector is supposed to resolve it: clear it or reallocate it. This drive did neither. It wrote to the bad sectors, failed, and instead of retiring them it just... kept adding to the pending pile. Fifty-eight blocks came back unrecoverable on the verify pass — the write itself didn't take, and the read afterward confirmed it with a medium error at the kernel level.

A drive whose Reallocated_Sector_Ct is frozen at zero while its pending count grows under forced writes is not a healthy drive with a clean record. It's a drive whose defect-management system has stopped retiring sectors. The zero isn't purity. It's paralysis. The one mechanism that's supposed to keep a drive limping — quietly swapping bad sectors for spares — is broken, and every new bad sector now just accumulates in the open with nowhere to go.

Verdict: failing. Not "keep an eye on it." Failing.

The rule#

Line the two up:

The drive with 344 reallocated sectors was the safe one. The drive with zero was the corpse. The static count inverted the truth in both directions at once, which is a lot of wrong for one attribute.

So stop reading the raw Reallocated_Sector_Ct as a health score. It's a scar count, and scars mean the drive survived something. What you want to know is whether the defect-management machinery still runs, and you find that out by forcing it to run: a destructive write pass, then a diff of the counters.

• Reallocated moves and pending drops → firmware is retiring bad sectors. Worn, stable, trustworthy.
• Reallocated frozen while pending grows → firmware can't retire anything. Failing, regardless of how low the count is.

The number at rest lies. The delta under load tells the truth.

The SMART attributes that actually matter#

• 5 — Reallocated_Sector_Ct. Sectors already retired to spare. A count of past saves, not current health. Reads on its own tell you little.
• 197 — Current_Pending_Sector. Sectors that failed a read and are unstable, awaiting a write to decide their fate. This is the live wound.
• 198 — Offline_Uncorrectable. Uncorrectable errors found during background scans. Tracks alongside pending.
• 187 — Reported_Uncorrect. Read errors ECC couldn't recover. On a shelved drive these freeze into a fossil record; on a dying one they climb.
• 188 — Command_Timeout. Operations aborted on timeout — as often a power or cabling symptom as a media one. Worth knowing when a drive lived in a bad enclosure.

Watch the movement of 5 relative to 197 under a forced write. That relationship is the diagnosis. Everything else is context.

sdd, the Toshiba, is a confirmed corpse — but a corpse with a strange autopsy: all 58 bad blocks landed in the first 5.2% of the platter. The rest of the disk wrote and verified clean. Which raises a question this post doesn't answer: can you carve the drive up, wall off the wound, and reclaim the healthy 94% as disposable scratch space? That's the next post — salvaging a dying disk by partitioning around the wound. This one was the diagnosis. That one is what you do with the body.

Filed under: linux, storage, smart

Read next#

• Salvaging a dying disk by partitioning around the wound — what I did with the drive this post condemned, and why it still gave back 6.7 TiB
• Designing alerts you'll actually understand at 3am — turning "the delta is what matters" into an alert that only fires when a counter actually moves
• All four drives at once, and why that was the good news — the failure mode that looks catastrophic and isn't a drive problem at all

Sources#

• Current Pending Sector Count — mdrepairs — the pending → reallocate-on-write sequence, in plain terms.
• Sector reallocation explained — DiskTuna — why reallocation happens on write, not read.
• badblocks — ArchWiki — destructive write mode; firmware only learns of a bad sector on an actual read/write.
• Reading SMART reports — helpful.knobs-dials — the attribute-197 gloss: "we'll only know when we next write to it."
• Pending sector, how to force reallocate — TrueNAS forums — forcing reallocation with writes, and the replace-vs-resurrect debate.
• Offline Uncorrectable (198) — Acronis — attribute 198 semantics.