Reallocated_Event_Count vs Reallocated_Sector_Ct: reading both together

Two SMART attributes track the same underlying process, sector reallocation, but count different things. Attribute ID 5 (Reallocated_Sector_Ct) counts sectors the drive has permanently retired and replaced with spares. Attribute ID 196 (Reallocated_Event_Count) counts remap operations the firmware initiated. When each bad sector fails individually and is remapped one at a time, the two counters move in lockstep. When a single physical event damages multiple sectors at once (head slap, thermal hotspot, manufacturing defect), the counters diverge: ID 196 increments once for the event while ID 5 jumps by the number of sectors involved.

Reading only one attribute hides the shape of the failure. ID 5 tells you sectors are being consumed from the spare pool but not whether failures are isolated point defects or cluster damage. ID 196 tells you event frequency but not whether each event costs one sector or fifty. Reading both alongside Current Pending Sector (ID 197) and Offline Uncorrectable (ID 198) reveals whether the drive is successfully remapping bad sectors or losing data.

What each attribute counts

Both attributes are cumulative, monotonically increasing counters maintained by drive firmware.

ID 196 counts operations, ID 5 counts outcomes. ID 196 increments on both successful and unsuccessful remap attempts. A single event may relocate multiple sectors (ID 5 jumps by N) if damage is clustered. If a remap fails because the data is unrecoverable, ID 196 still increments but ID 5 does not.

Neither counter decreases under normal operation. A decrease without a firmware update or drive swap is a red flag.

How the reallocation lifecycle works

When firmware detects an unreliable sector during a read or write:

1. The sector is flagged as pending (ID 197 increments). The drive has found it unreliable but has not yet attempted a remap.
2. On the next write to that sector, or during an offline scan, the firmware attempts a remap. ID 196 increments by one.
3. The remap succeeds or fails:
   • Success: data is relocated to a spare, the original location is retired, ID 5 increments by the number of sectors involved, and ID 197 decreases.
   • Failure: data cannot be recovered or rewritten. The sector becomes permanently uncorrectable (ID 198 increments). ID 5 does not increment.

flowchart TD
    A["Sector read fails"] --> B["ID 197 +1
sector flagged pending"]
    B --> C["Write or offline scan
triggers remap attempt"]
    C --> D["ID 196 +1
remap event recorded"]
    D --> E{"Data recovered?"}
    E -->|"Yes: moved to spare"| F["ID 5 +N sectors
ID 197 decrements"]
    E -->|"No: unrecoverable"| G["ID 198 +N
ID 5 unchanged"]
    F --> H["Spare pool consumed"]
    G --> I["Permanent data loss"]

A sector can also self-resolve. The drive may regain confidence in a pending sector on a subsequent read and clear it without incrementing ID 5 or ID 196. If you see ID 197 fluctuate without corresponding changes in ID 5 or ID 196, the drive may be experiencing intermittent read failures that self-correct.

When the two counters diverge

The ratio between ID 5 and ID 196 is the diagnostic signal.

1:1 ratio (sectors match events). Each remap event costs one sector. Isolated point failures, typically normal media aging. The spare pool is consumed at a predictable rate.

N:1 ratio (sectors exceed events). Each remap relocates multiple sectors. Cluster damage: a physical event damaged a contiguous region of the platter (HDD) or a NAND block group (SSD). Common causes include head slap, impact, thermal damage, or a regional manufacturing defect. Concentrated damage suggests an accelerating physical process, not random aging.

Events exceed sectors. ID 196 is incrementing but ID 5 is not growing proportionally. Remap attempts are failing. The most likely cause is pending sectors becoming uncorrectable (check ID 198) or the spare pool nearing exhaustion. This is the terminal phase: the drive is trying to compensate but cannot.

Pairing with ID 197 and ID 198

ID 5 and ID 196 tell you the shape of the failure. Adding ID 197 and ID 198 tells you whether the drive is winning or losing the reallocation battle.

The most dangerous pattern: ID 196 rising while ID 5 stays flat and ID 198 climbs. The drive is attempting remaps but failing. Data is being lost. This often precedes the drive going read-only or dropping off the bus entirely.

Vendor quirks and common misreads

Seagate firmware quirk. Some Seagate models report Reallocated_Event_Count in the hundreds or thousands while Reallocated_Sector_Ct remains at zero. This is not failed remapping. Seagate uses attribute 196 in a proprietary way on certain firmware variants. The raw value may also appear as a multi-field number, for example “21714 (30258 0)”, where the first number is the primary count and the parenthetical values are vendor-specific sub-fields. Track the first number. Before alarming on ID 196 alone, verify the drive model and cross-check ID 5, ID 197, ID 198, and the ATA error log. If those corroborating signals are all clean, the high ID 196 value is firmware behavior, not media degradation. Community reports identify specific models rather than a universal firmware boundary, so use smartctl -P show and model-specific reports when deciding how much weight to give it.

SSD attribute naming. On SSDs, attribute 5 may use vendor-specific names that differ from the standard “Reallocated_Sector_Ct.” The concept of individual “sectors” does not map cleanly to NAND pages and blocks. Attribute 196 may still appear with sector-based naming that does not reflect how SSD controllers manage bad blocks. On SSDs, interpret ID 5 and ID 196 in the context of available spare capacity and percentage used rather than as direct sector counts. Native NVMe devices do not use these ATA IDs; they report the standard NVMe health-log fields. An NVMe drive behind a translation layer may synthesize or omit ATA-style attributes, so verify what the bridge actually exposes. The SSD reallocation lifecycle is controller-specific: it retires blocks and activates spares from over-provisioned capacity as part of wear management, not necessarily in response to individual sector read failures.

Multi-field raw values. smartctl may display raw values as a primary number followed by parenthetical sub-fields. The sub-fields are vendor-specific and not standardized. Track the primary number (the value before the parentheses) for both ID 5 and ID 196.

Counter resets from diagnostics. Manufacturer diagnostic tools or sector repair utilities can force the drive to attempt reallocation, which may reset Current Pending Sector (ID 197) to zero while incrementing ID 5. The drive looks healthier on ID 197 alone, but ID 5 reveals the underlying problem. Monitor all four attributes: any single attribute can be masked or reset, but the combination reveals the full picture.

Collecting both attributes

The following commands assume SATA or SAS drives. NVMe drives use a different SMART health log model and may not expose these attributes through the same path.

# Show both reallocation attributes in one pass
smartctl -A /dev/sda | grep -iE "Reallocated"

# Or extract specific IDs with their raw values
smartctl -A /dev/sda | awk '$1 == 5 || $1 == 196 {print}'

Both commands require read access to the device, typically root or membership in the disk group. The awk alternative keys on the attribute ID in the first column and prints the complete row, which matters when a vendor RAW_VALUE contains spaces or parenthetical sub-fields.

For trend tracking, capture snapshots periodically and diff:

# Capture a snapshot for later comparison
smartctl -A /dev/sda | grep -iE "Reallocated" > /tmp/smart_realloc_$(date +%s).txt

# Compare two snapshots
diff /tmp/smart_realloc_<older> /tmp/smart_realloc_<newer>

Alert on the RAW_VALUE column, not the normalized VALUE column. The normalized value is vendor-interpreted and thresholds are set conservatively.

Signals to watch in production

Rate of change matters more than absolute value. A drive with 5 reallocated sectors accumulated over three years is stable. A drive that gained 5 reallocated sectors in the last week is actively degrading. A sudden shift from a 1:1 to a 10:1 ID 5 to ID 196 ratio means the failure pattern changed from isolated point defects to cluster damage, which is a different operational concern.

Correlating with Netdata

Netdata collects SMART raw values per second per drive. For reallocation tracking, this helps in three specific ways:

• Rate-of-change detection. Per-second collection catches ID 5 or ID 196 shifts before absolute thresholds trip. The actionable signal is the rate, not the count.
• Multi-attribute correlation. Viewing ID 5, ID 196, ID 197, and ID 198 on a single timeline shows whether the drive is clearing pending sectors or accumulating uncorrectable ones, without manual smartctl cross-referencing.
• Fleet-level aggregation. When multiple drives of the same model and firmware show similar reallocation patterns simultaneously, batch defects surface quickly.

ML-based anomaly detection can flag gradual ratio shifts (1:1 drifting toward N:1) that simple threshold alerts miss. Per-drive baselines also account for factory-shipped reallocated sectors, preventing false alarms on drives that shipped with a small nonzero count from manufacturing QA.

Related guides

• How S.M.A.R.T. actually works: a mental model for operators
• smartctl disk monitoring checklist: the SMART signals every server needs
• SMART monitoring maturity model: from survival to expert
• Reallocated_Sector_Ct rising: the drive is burning through its spare pool