Self-test completed: read failure - a bad sector found by proactive scanning

When smartctl -l selftest /dev/sdX shows “Completed: read failure”, the drive’s firmware found a sector it cannot read during an active surface scan. The LBA_of_first_error column gives you the exact logical block address of the defect. The firmware tried multiple times, exhausted its error correction, and could not recover the data at that location.

The extended self-test scans the entire media surface. Without it, a bad sector remains hidden until production I/O hits that exact LBA, producing an application-visible I/O error, a hung process, or a kernel timeout instead of a diagnostic warning.

The data at the reported LBA is lost unless you have redundancy (RAID, replication, or a checksumming filesystem like ZFS or Btrfs that can self-heal). The drive has a problem. The questions are: how bad is it, is it spreading, and how fast do you need to replace the drive.

What this means

“Completed: read failure” means the drive’s internal surface scan hit a sector where the read failed after the firmware’s standard retry and ECC recovery cycle. The Remaining column tells you how far into the scan the defect was found.

The key fields in the self-test log:

• Status: “Completed: read failure” confirms the failure type.
• Remaining: Percentage of the test that did not run. “90%” remaining means the test failed after scanning roughly 10% of the surface.
• LBA_of_first_error: Logical block address (in 512-byte sectors, starting at zero) where the read failed. This is the defect location.
• LifeTime(hours): Power-on hour count when the test ran, giving you a timeline.

The self-test reports the first bad sector it encounters. If Remaining shows a high percentage, the defect was found early. There may be additional bad sectors further along the media that the test never reached.

A read failure in the self-test log does not tell you whether the sector was reallocated. The firmware may or may not have remapped it to a spare. Check Current_Pending_Sector, Reallocated_Sector_Ct, and Offline_Uncorrectable to understand the current state of the defect.

Full self-test result taxonomy:

A passing extended test (“Completed without error” with 00% remaining and no LBA) is strong evidence of media integrity across the full surface. A failing one gives you the exact defect LBA, which is actionable intelligence you cannot get any other way without waiting for production I/O to hit the bad sector.

Common causes

Quick checks

These commands are safe and read-only.

# Check self-test log: note the LBA_of_first_error and Remaining %
smartctl -l selftest /dev/sdX

# Check error log for UNC errors at the same LBA
smartctl -l error /dev/sdX

# Check media integrity attributes
smartctl -A /dev/sdX | grep -iE "Reallocated|Current_Pending|Offline_Uncorrect"

# Check overall health assessment
smartctl -H /dev/sdX

# Check kernel logs for I/O errors on this device
dmesg | grep -iE "I/O error|medium error" | grep sdX | tail -20

# For NVMe: check media errors and spare capacity
smartctl -A /dev/nvme0n1 | grep -iE "Media and Data|Available Spare|Percentage Used"

How to diagnose it

flowchart TD
    A["Self-test shows
read failure at LBA"] --> B["Check IDs 197, 198, 5"]
    B --> C{"Pending 197 or
Uncorrectable 198 rising?"}
    C -- Yes --> D["Active media degradation
plan drive replacement"]
    C -- No --> E["Run another extended test"]
    E --> F{"Same LBA fails again?"}
    F -- Yes --> D
    F -- No --> G["Single transient event
monitor for recurrence"]

1. Record the LBA and Remaining percentage. Save this for comparison after the next test.

2. Check Current_Pending_Sector (ID 197). If non-zero, the failed sector is in the pending queue awaiting reallocation. A write to that LBA would force the firmware to attempt reallocation. If the value is zero, the sector may have already been reallocated or was transient.

3. Check Reallocated_Sector_Ct (ID 5). If it increased from your baseline, the firmware already remapped the bad sector to a spare. The data at the original LBA is gone, but the drive compensated. Track how many spares have been consumed.

4. Check Offline_Uncorrectable (ID 198). If it increased, the drive confirmed the sector is permanently unreadable. This is confirmed data loss at the media level. Attribute names and IDs can vary between manufacturers, so verify the decoded attribute name rather than relying solely on the ID number.

5. Check the ATA error log. Run smartctl -l error /dev/sdX and look for UNC (uncorrectable) errors. If the error log shows UNC errors at the same LBA as the self-test failure, the defect is confirmed from multiple angles. The ATA summary error log holds only 5 entries; use smartctl -l xerror for the extended log if available.

6. Run another extended test. Start a new test with smartctl -t long /dev/sdX. This takes hours on large HDDs. Compare the new result:

   • Same LBA fails again: persistent physical defect.
   • Different LBA fails: multiple bad sectors, or a failing head/arm assembly on an HDD.
   • Test passes: the original failure may have been transient (vibration, power glitch), or a write to the sector forced reallocation and cleared the defect.

7. Map the LBA to a filesystem object (optional). The BadBlockHowto from the smartmontools project describes the procedure for translating a raw LBA to a filesystem block and identifying the affected file. If you run ZFS or Btrfs, a scrub will report checksum errors on the affected files directly.

Metrics and signals to monitor

Fixes

Single isolated defect, drive otherwise healthy

If the read failure is at one LBA, Current_Pending_Sector is non-zero but small, and no other attributes are rising, you can attempt to force reallocation. Writing to the pending LBA triggers the firmware to attempt a remap to a spare sector. If the write succeeds, the sector drops off the pending list and Reallocated_Sector_Ct increments by one.

This is a bandaid, not a repair. The underlying media degraded enough to produce an unreadable sector. Forcing reallocation clears the symptom but consumes a spare from a finite pool. On a production drive, plan replacement regardless.

Warning: Any procedure that writes directly to a specific LBA is destructive. The data at that LBA is already unreadable, but you must ensure you are targeting the correct sector and not corrupting adjacent data. The smartmontools BadBlockHowto documents the safe procedure: map the LBA to a filesystem block, verify the mapping, and write only that block.

Active media degradation (multiple signals)

If Current_Pending_Sector or Offline_Uncorrectable are non-zero and rising alongside the self-test failure, the drive is in active decline. The spare pool is being consumed. Do not attempt sector-by-sector repair. Replace the drive.

Steps:

1. Verify all backups and redundancy for this drive are current.
2. If the drive is in a RAID array, initiate a controlled replacement (add spare, rebuild) rather than waiting for an uncontrolled failure during peak load.
3. If the drive is standalone, migrate data immediately and schedule replacement.
4. After replacement, run an extended self-test on the new drive during the first 24-48 hours. RAID rebuilds stress-test replacement drives and can surface latent manufacturing defects.

Self-test keeps getting aborted

If the self-test log shows repeated “Aborted by host” or “Interrupted (host reset)” entries, the test is not finishing. Extended self-tests compete with host I/O for the drive’s command queue, and heavy production load can starve the test. This is a scheduling problem, not a drive problem. Schedule extended tests during low-load windows. The smartd daemon can automate scheduled tests in smartd.conf using the -s directive.

Prevention

Schedule periodic extended self-tests. Drives do not run self-tests automatically. Without scheduled tests, latent bad sectors remain hidden until production I/O hits them. A monthly extended test is standard practice; a weekly short test catches mechanical and electrical issues but only scans a limited portion of the media.

Baseline drives at deployment. Capture a full SMART snapshot when a drive enters service. This lets you distinguish “shipped with 3 reallocated sectors from factory” from “developed 3 reallocated sectors in production.”

Track rate of change, not absolute values. A drive with 10 reallocated sectors accumulated over 5 years is stable. A drive with 2 reallocated sectors gained this week is actively degrading. Growth rate is the most actionable signal for predicting failure timeline.

Check self-test results after every run. A self-test whose results are never checked provides no value. Automate result collection and alert on any non-passing result.

Use checksumming filesystems. ZFS and Btrfs scrubs read every block, surfacing latent defects the same way an extended self-test does. A scrub that triggers reallocated sector growth is revealing damage that already existed, not causing it.

How Netdata helps

Netdata’s SMART monitoring collects the attributes that matter for this failure mode:

• Rate-of-change on IDs 5, 197, 198: Instead of alerting on absolute values (which produces false alarms on drives with historical counts), Netdata tracks growth over time. A single new reallocated sector in a 24-hour window is flagged; a stable count from years ago is not.
• Correlation with I/O latency: When a self-test finds a bad sector, Netdata can correlate the event with await spikes in disk metrics, confirming that production I/O is already affected by retry loops on pending sectors.
• Fleet-wide visibility: If multiple drives of the same model show self-test failures around the same power-on hour count, that pattern points to a batch defect. Per-drive monitoring alone misses this.

Related guides

• Current_Pending_Sector non-zero: unreadable sectors and I/O latency spikes
• 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
• Offline_Uncorrectable climbing: permanent data loss at the media level
• Raw_Read_Error_Rate looks enormous: the Seagate false alarm explained
• Reallocated_Event_Count vs Reallocated_Sector_Ct: reading both together
• Reallocated_Sector_Ct rising: the drive is burning through its spare pool