$ guides / smartctl-disk-monitoring / smartctl-reallocated-sectors ▌

Operations Guides

Reallocated_Sector_Ct rising: the drive is burning through its spare pool

When smartctl -A shows Reallocated_Sector_Ct (SMART attribute ID 5) climbing, the drive firmware is silently remapping sectors that have become unreliable. Each reallocation consumes a sector or block from a finite spare pool reserved at the factory. Once that pool is exhausted, the next bad sector becomes an uncorrectable read error. Data loss follows.

The absolute count tells you less than the rate of change. A drive with 10 reallocated sectors that has been stable for 3 years is operating within its tolerances. A drive that gained 10 reallocated sectors in the last week is actively failing.

What this means

Reallocated_Sector_Ct counts sectors (HDD) or NAND blocks (SSD) that the drive firmware has permanently retired and replaced with spares. The remapping is transparent to the host operating system. You never see the original bad location, only the incremented counter in SMART output.

The drive maintains three internal structures relevant to this attribute:

Spare pool: finite reserve capacity used for remapping. Its size varies by drive model and is rarely exposed directly.
Pending list: sectors flagged as unstable during reads that have not yet been remapped (attribute ID 197).
Defect list: sectors already remapped (reflected in the reallocated count).

The spare pool degrades on a cliff-edge curve. The drive operates normally while spares are available. When the last spare is consumed, there is no graceful degradation. The next defect is an uncorrectable error with no remaining capacity to remap it.

flowchart TD
    A["Sector fails read or write"] --> B["Firmware attempts recovery"]
    B -->|"Recovered via ECC"| C["Sector remains in service"]
    B -->|"Unrecoverable"| D["Remap from spare pool"]
    D --> E["ID 5 Reallocated_Sector_Ct increments"]
    D --> F["ID 196 Reallocated_Event_Count increments"]
    E --> G{"Spare capacity remaining?"}
    G -->|"Yes"| H["Drive continues operating"]
    G -->|"No"| I["Next defect = permanent data loss"]

Common causes

Cause	What it looks like	First thing to check
Progressive platter surface degradation (HDD)	Slow steady increase in ID 5 over weeks or months; ID 197 may also be non-zero	`smartctl -l error` for UNC errors at specific LBAs
NAND cell wear-out (SSD)	ID 5 rising alongside declining wear leveling count or NVMe Percentage Used approaching 100%	Check vendor wear attributes (Samsung ID 177, Intel ID 233, NVMe Percentage Used)
Head crash aftermath (HDD)	Sudden large jump in reallocated count after a physical event	Correlate with G-Sense Error Rate (ID 221 or 191) and dmesg I/O errors
Thermal damage to media	Reallocated sectors appearing alongside sustained high temperature	Check ID 194 temperature and SCT temperature history with `smartctl -l scttemp`

Quick checks

All commands are read-only and safe on a production system.

# Check reallocated, pending, uncorrectable, and event counts together
smartctl -A /dev/sdX | grep -iE "Reallocated|Current_Pending|Offline_Uncorrectable|Reallocated_Event"

# Full attribute table with normalized values
smartctl -a /dev/sdX

# Overall health self-assessment
smartctl -H /dev/sdX

# Error log for UNC errors with affected LBAs
smartctl -l error /dev/sdX

# Extended error log for more entries than the summary log
smartctl -l xerror /dev/sdX

# Self-test results and history
smartctl -l selftest /dev/sdX

# I/O latency correlation (watch the await column)
iostat -x 1

# Kernel I/O errors, resets, and timeouts for this device
dmesg | grep -iE "I/O error|medium error|reset|timeout" | tail -20

How to diagnose it

1. Capture a full SMART snapshot.

Run smartctl -a /dev/sdX and save the output. This is your working baseline. Compare it against any previous snapshot from your monitoring system or deployment records.

2. Determine the rate of change.

This is the single most important step. If you have monitoring history, plot the reallocated count over time. When did the count start increasing, and is the rate accelerating?

Stable for months: The drive contained a defect, possibly from manufacturing, and has been operating fine. TICKET severity. Monitor for growth.
Increasing over days or weeks: Active degradation. The drive is consuming spares at a rate that indicates progressive failure.
Sudden large jump: Likely a physical event such as a head crash, shock, or power surge. Investigate G-Sense Error Rate and kernel logs for correlated events.

3. Check for the Seagate raw-value encoding gotcha.

Seagate drives encode some SMART attributes differently than other manufacturers. The raw value field can pack multiple sub-fields together, producing enormous numbers that look alarming but represent normal operation. If the normalized VALUE column is at 100 (or 200) and stable, but the raw value looks absurdly large, suspect encoding rather than actual sector failure.

For Seagate IronWolf HDDs with SC60 firmware, smartmontools 7.4 and 7.5 do not define a special attribute-5 override in drivedb.h; the default ATA profile applies raw16(raw16),Reallocated_Sector_Ct. Do not assume that SC60 uses a special 48-bit mixed counter. Use the normalized value together with IDs 196, 197, and 198, and compare raw values only against the same model and firmware.

4. Correlate with companion attributes.

The decision to escalate depends on what the companion attributes show alongside the rising reallocated count:

Attribute	What to check	Interpretation
ID 197 (Current_Pending_Sector)	Is it non-zero?	Non-zero means the drive has sectors it cannot reliably read that have not yet been remapped. These are candidates for future reallocation or permanent data loss.
ID 196 (Reallocated_Event_Count)	Is it rising?	Counts reallocation events, which may differ from the sector count if multiple sectors were reallocated in one event. A high 196 with a low 5 can indicate many failed reallocation attempts.
ID 198 (Offline_Uncorrectable)	Is it increasing from baseline?	Confirmed data loss at the sector level. The drive tried to recover the data and failed.
SMART Overall Health	Is it FAILED?	The drive firmware itself considers a pre-fail attribute to have crossed its vendor-defined threshold.

5. Run an extended self-test.

# Start an extended self-test (takes hours on large HDDs, impacts I/O performance)
smartctl -t long /dev/sdX

After completion, check results with smartctl -l selftest /dev/sdX. A result of “Completed: read failure” at a specific LBA confirms a media defect the drive found during proactive scanning. “Completed without error” provides strong evidence of media integrity for the tested region.

6. Check host-level I/O latency.

Use iostat -x 1 and look for high await values on the suspect drive. When the drive retries reads on failing or pending sectors, individual I/O operations hang for seconds. This manifests as high iowait with low CPU utilization, a pattern often misdiagnosed as a software or network issue. If you see this alongside non-zero pending or reallocated sectors, the drive is already impacting production I/O.

When to page

PAGE severity for rising reallocated sectors requires all of the following conditions simultaneously:

Reallocated sectors increased by 5 or more in a 24-hour window.
Current Pending Sectors (ID 197) is non-zero sustained across at least 2 consecutive polls.
At least one corroborating hard-failure signal:
- Offline Uncorrectable (ID 198) also increased, OR
- Self-test completed with read failure, OR
- SMART Overall Health is FAILED.

This multi-condition requirement prevents false pages from isolated reallocation events. A single sector reallocation, even on a production drive, does not warrant waking someone at 3 a.m. The combination of rising reallocation plus sustained pending sectors plus a hard-failure corroboration confirms active multi-signal media failure.

Any non-zero reallocated count that does not meet the PAGE criteria is a TICKET: investigate and begin replacement planning.

Metrics and signals to monitor

Signal	Why it matters	Warning sign
Reallocated_Sector_Ct (ID 5) raw value	Tracks spare pool consumption directly	Any increase from previous reading
Reallocated_Sector_Ct (ID 5) normalized VALUE	Manufacturer health assessment on a vendor-specific scale	Declining toward the THRESH column value
Current_Pending_Sector (ID 197)	Sectors failing reads but not yet remapped	Any non-zero value sustained across polls
Offline_Uncorrectable (ID 198)	Confirmed unrecoverable data at the sector level	Any increase from baseline
Reallocated_Event_Count (ID 196)	Counts reallocation attempts including failures	Rising faster than ID 5, suggesting failed remapping
SMART Overall Health	Drive firmware binary pass or fail	FAILED
I/O latency (await in iostat)	Host-visible impact of drive retry loops	await in seconds with high iowait and low CPU
ATA Error Log	Detailed error events with specific LBAs	UNC errors at specific LBAs
Self-test results	Proactive surface scan findings	“Completed: read failure” with a reported LBA

Fixes

Replace the drive

This is the only real fix for a drive with a rising reallocated count. The spare pool does not regenerate. Once sectors are being remapped at an accelerating rate, the drive is on a failure trajectory that will end in data loss if not addressed.

For drives in a RAID array, initiate a controlled replacement (add hot spare, trigger rebuild) now rather than waiting for an uncontrolled failure during peak traffic. A RAID rebuild is sustained sequential write pressure on the replacement drive, so watch SMART attributes closely during the first 24 to 48 hours. If the new drive has a latent defect, the rebuild will surface it.

Force reallocation of pending sectors (temporary measure, not a fix)

If the drive has pending sectors (ID 197 non-zero) causing I/O latency stalls but the reallocated count is still manageable, you can force the drive to attempt reallocation by writing to the affected sectors. The smartmontools BadBlockHowto documents the canonical procedure: identify the LBA from the self-test log or error log, calculate the corresponding filesystem block, and write to that block using dd or hdparm --write-sector.

Warning: This is destructive. It overwrites the data at the target LBA. The write triggers the drive to attempt reallocation, which consumes another spare sector. This buys time for a planned replacement but accelerates spare pool consumption. It does not fix the underlying media degradation.

Investigate cable issues before replacing

If UDMA CRC Error Count (ID 199) is also rising alongside the reallocated count, part of the problem may be the cable or backplane, not the drive alone. CRC errors can cause phantom pending sectors: the data transfer fails on the wire, so the drive marks the sector as suspect even though the on-disk data is intact. Fix the cable first (reseat, then replace with a known-good cable), then re-evaluate whether reallocated and pending sectors continue to grow.

The distinguishing pattern: CRC errors rising with zero media errors (IDs 5, 197, 198 all clean) points to the transport layer. CRC errors rising alongside media errors means both problems coexist.

Prevention

Baseline every drive at deployment. Capture a full smartctl -a snapshot when the drive is installed. Some drives ship with a small number of reallocated sectors from factory provisioning. Without a baseline, you cannot distinguish factory defects from production failures.
Track rate of change, not just absolute values. A monitoring system that alerts on “ID 5 greater than 0” will fire on every drive that shipped with a minor factory defect. Alert on growth from the previous reading instead.
Schedule extended self-tests. Drives do not run self-tests automatically. Without periodic extended tests, latent bad sectors remain hidden until production I/O hits them. Weekly short tests and monthly long tests are standard practice.
Do not rely on SMART PASSED alone. A drive can report PASSED while having dozens of reallocated sectors and non-zero pending sectors. Manufacturer thresholds are conservative. By the time SMART says FAILED, the drive has been dying for weeks.
Watch for the attribute zeroing trick. Manufacturer diagnostics and some tools can force sector reallocation, which resets Current Pending Sector (ID 197) to zero. The drive looks healthier, but Reallocated Sector Count (ID 5) will have increased. Monitoring only ID 197 misses this pattern.
Account for first-observation bootstrap. When deploying SMART monitoring on an existing fleet for the first time, every drive with any history will have non-zero cumulative counters. The monitoring system must establish a baseline on first scrape and alert on growth from that point, not on the absolute value. Paging on lifetime values at first deployment floods operators with false alarms.

How Netdata helps

Netdata’s smartctl collector surfaces SMART attributes at per-second granularity, which directly supports the rate-of-change analysis this diagnosis depends on:

Rate-of-change tracking: Netdata stores attribute values over time, so you can see whether reallocated sectors are stable or accelerating without manually diffing snapshots between polls.
Multi-signal correlation on one timeline: The dashboard places ID 5, ID 196, ID 197, and ID 198 side by side, making the PAGE condition (rising reallocated plus non-zero pending plus a hard-failure corroboration) visible at a glance rather than requiring four separate queries.
ML anomaly detection on SMART trends: Netdata’s anomaly advisor flags unusual changes in attribute trends before they cross hard thresholds, which catches the slow steady increase that absolute-value alerting misses.
Host-level I/O metrics alongside SMART data: Netdata collects per-disk I/O latency, queue depth, and iowait on the same timeline as SMART attributes, so you can correlate the retry-loop pattern (high await, low CPU, rising pending sectors) in a single view.
Baseline management for fleet-wide deployment: On first deployment, Netdata establishes per-drive baselines and can alert on growth rather than absolute lifetime values, preventing the alert storm that occurs when monitoring is first enabled across an existing fleet.