$ guides / smartctl-disk-monitoring / smartctl-self-test-aborted ▌

Operations Guides

SMART self-tests keep aborting: heavy I/O interrupting the extended scan

The self-test log tells the same story every time. You started an extended self-test with smartctl -t long /dev/sdX, checked back hours later, and found another entry reading “Aborted by host” or “Interrupted (host reset)”. The drive reports no read failures, no servo errors, no electrical faults. But the full surface scan never actually completed.

This is a scheduling problem, not a drive health problem. ATA extended self-tests run in background mode by default, meaning the test has low priority and yields to host I/O. On a busy production drive, the test keeps getting deferred and eventually aborted. Latent bad sectors remain undiscovered until production I/O hits them.

What this means

The self-test log distinguishes between two abort conditions, each pointing to a different root cause:

“Aborted by host” (status code 0x1 in the ATA self-test log): The host explicitly cancelled the test. Common triggers include issuing smartctl -X, rebooting the system, entering sleep or suspend, starting a new test that overrides the running one, or the drive spinning down to standby due to power management.
“Interrupted (host reset)” (status code 0x2): The host reset the SATA or SAS link. This typically happens because a command timed out at the kernel level and the error handler issued a bus reset, or a controller or driver bug triggered an unwanted link reset.

Neither status indicates media failure. The drive is not reporting bad sectors, mechanical problems, or electrical faults. The problem is operational: the test never ran to completion.

A single abort entry is benign. A pattern of aborts across every extended test means the drive has not been fully scanned in weeks or months. Extended self-tests are the most thorough proactive mechanism for discovering latent bad sectors before production I/O reaches them. Without completed scans, your earliest warning of media degradation becomes an I/O error in production.

flowchart TD
    A["Repeated self-test aborts"] --> B{Which abort type?}
    B -->|"Aborted by host"| C["Spindown, reboot,
or heavy I/O deferral"]
    B -->|"Interrupted host reset"| D["Captive mode timeout,
controller reset, or USB"]
    C --> E["Disable standby timer,
reschedule for low I/O"]
    D --> F["Drop -C flag,
check dmesg for resets"]
    E --> G["Extended test completes"]
    F --> G

Common causes

Cause	What it looks like	First thing to check
Drive spindown or power management	“Aborted by host” when the drive transitions to standby; a very early abort can show high “remaining,” such as 90%	Check standby timer and APM settings
Heavy host I/O contention	Test runs briefly, then aborts during peak workload hours. Progress varies.	`iostat -x 1` on the target drive during the test window
Captive mode timeout bug	“Interrupted (host reset)” within seconds of starting `smartctl -t long -C`. Kernel log shows command timeout and link reset.	Check whether you are passing `-C` (captive/foreground mode)
Controller or NCQ firmware bug	Tests abort intermittently, especially when testing multiple drives simultaneously. Link resets appear in kernel logs.	`dmesg \| grep -iE "reset\|timeout" \| tail -20`
USB bridge timeout	“Interrupted (host reset)” on USB-attached drives. The USB-to-SATA bridge has its own timeout or aggressive power management.	Confirm connection type with `lsblk -S`
System reboot or crash	One-off “Aborted by host” that correlates with a known reboot or crash event.	Compare uptime against the test timestamp

Quick checks

# Check the self-test log for abort patterns
smartctl -l selftest /dev/sdX

# Check if a test is currently in progress
smartctl -c /dev/sdX

# Check I/O activity on the target drive
iostat -x 1 /dev/sdX

# Look for link resets and command timeouts in kernel logs
dmesg | grep -iE "reset|link|timeout|I/O error" | tail -20

# Check overall SMART status and power management info
smartctl -a /dev/sdX

# Check APM level (SATA HDDs)
hdparm -B /dev/sdX

How to diagnose it

Read the self-test log. Run smartctl -l selftest /dev/sdX and look at the pattern. Is every extended test aborted? What percentage completed before each abort? When a test is aborted early, the percentage remaining may show a high value like 90%. This does not mean the test was nearly complete; it means the test barely started.
Identify the abort type. “Aborted by host” points toward spindown, reboot, or explicit cancellation. “Interrupted (host reset)” points toward command timeouts, controller resets, or captive mode issues.
Check for spindown. If the drive has aggressive power management, it may spin down during the multi-hour extended test. When the drive transitions to standby, the running self-test is aborted. Check the APM level with hdparm -B /dev/sdX and look for a standby timer with hdparm -I /dev/sdX | grep -i standby.
Check I/O load during the test window. Extended tests in background mode yield to host I/O. If the drive is under sustained load, the test may never make enough progress to complete within the system’s timeout or reset window. Use iostat -x 1 /dev/sdX to measure throughput and queue depth during the test.
Check for captive mode usage. If you are running smartctl -t long -C /dev/sdX, the -C flag puts the test in captive (foreground) mode. The kernel may time out the ATA passthrough command long before an extended test can finish; operator reports commonly cite about 20 seconds on affected Linux/libata stacks, but the exact value varies by kernel and driver configuration. The kernel times out, resets the link, and the test aborts with “Interrupted (host reset)”. Smartmontools community reports identify this as ticket #303, and a related captive-mode case as ticket #1153; both were reported as wontfix.
Check kernel logs for controller resets. Run dmesg | grep -iE "reset|timeout" and look for patterns that correlate with your test start times. SATA link resets, SCSI error handler invocations, and controller firmware bugs can all abort a running self-test.
Check for NCQ or multi-drive interactions. Some controller and drive firmware combinations abort self-tests when Native Command Queuing is active, or when multiple drives are tested simultaneously. This has been documented with WD drives connected to Marvell SATA controllers.

Metrics and signals to monitor

Signal	Why it matters	Warning sign
Self-test completion status	Confirms the full surface was actually scanned	Repeated “Aborted by host” or “Interrupted (host reset)” entries with no completed tests
Disk I/O throughput and queue depth	Extended tests yield to host I/O; a saturated drive will never complete a scan	Sustained high `%util` or high `aqu-sz` during the scheduled test window
Drive power state transitions	Spindown to standby aborts any running self-test	APM level below 128 or standby timer enabled on the target drive
Kernel link reset events	Each reset aborts the running test	`dmesg` entries matching “link reset” or “hard reset” on the target device
Self-test log growth rate	The standard ATA SMART self-test log holds 21 entries; the optional extended self-test log defaults to 25 entries and vendor log size can vary. Old entries are overwritten	Log entries are all aborts with no completed tests
Reallocated and pending sector counts	Without completed scans, these may be the only indicators of latent media degradation	Any increase in ID 5 (Reallocated) or ID 197 (Current Pending) when no self-test has completed recently

Fixes

Fix drive spindown

Drive spindown is the most common cause of aborted extended tests on non-enterprise drives. Extended tests can take hours, and if the drive enters standby during that window, the test is aborted.

Options (all non-persistent across reboots):

Temporarily disable standby: hdparm -S 0 /dev/sdX. Note: this setting does not persist across reboot or kernel driver reload.
Poll the drive to keep it awake: while true; do smartctl -a /dev/sdX > /dev/null; sleep 60; done. The periodic SMART read prevents standby.
Set APM to maximum performance: hdparm -B 254 /dev/sdX. Not all drives support APM; some SSDs ignore this setting entirely. Restore the original setting after the test.

Schedule tests during low-I/O windows

If spindown is not the issue but the drive is too busy, reschedule the test. Extended tests yield to host I/O by design. On a production database drive or a busy storage node, the test may never get enough idle time to progress.

Identify the lowest-I/O window by monitoring iostat -x 1 over 24 hours. Schedule the extended test to start at the beginning of that window. On most systems this means overnight or during a maintenance period.

The smartd daemon can automate test scheduling. Configure it in /etc/smartd.conf to run extended tests at specific times, such as weekly during a low-traffic window.

Stop using captive mode for extended tests

If you are passing -C to smartctl -t long, stop. Captive mode holds the ATA command queue for the entire test duration. The kernel’s ATA passthrough timeout is far shorter than any extended test. The kernel times out the command, resets the link, and the test aborts.

This is a known limitation documented in smartmontools tickets #303 (2013) and #1153 (2018), both marked wontfix. Use background mode instead, which is the default when you omit -C.

If a previous test is still running and you need to start a new one, prefer smartctl -X /dev/sdX followed by the new -t command. smartctl also supports smartctl -t force /dev/sdX, which starts a new test even if one is already running; use it only when you intentionally want to interrupt the running test.

Work around controller and NCQ bugs

If kernel logs show link resets that correlate with test start times, and you are not using captive mode, the issue may be a controller or drive firmware bug interacting with NCQ.

One documented workaround for WD drives on Marvell SATA controllers is to set the queue depth to 1, effectively disabling NCQ:

# Disable NCQ on the target drive (temporary, degrades performance)
echo 1 > /sys/block/sdX/device/queue_depth

This is temporary and degrades I/O performance. Restore the original queue depth after the test. Running tests on multiple drives simultaneously on the same controller may still trigger resets even with this workaround.

Handle USB-attached drives

USB-to-SATA bridge controllers introduce their own timeout and power management behaviors that can abort self-tests. USB-attached drives are prone to “Interrupted (host reset)” aborts.

If you must test a USB-attached drive:

Use -d sat to ensure SMART commands pass through the bridge correctly.
Poll the drive periodically to prevent USB suspend from cutting power.
Smartmontools 7.5 fixed an issue where the -d sntjmicron device type triggered USB resets during self-test log queries on NVMe-over-USB devices (smartmontools issue #256). If running an older version, upgrading may resolve spurious resets.

Prevention

Schedule tests explicitly. Drives do not run self-tests automatically. Configure smartd to run a short test weekly and an extended test monthly during known low-I/O windows.
Verify completion, not just initiation. After each scheduled test, check smartctl -l selftest /dev/sdX to confirm the test actually completed. An alerting rule that fires when the most recent extended test result is not “Completed without error” catches the silent-abort pattern.
Disable aggressive power management on test nights. If the drive normally spins down, override the standby timer before the test starts and restore it afterward.
Test one drive at a time on suspect controllers. If you have observed controller or NCQ-related aborts, serialize your tests rather than running them in parallel across drives on the same controller.
Track the self-test log over time. The ATA self-test log has limited entries and old entries are overwritten. If your monitoring system does not capture the log externally, a history of aborts can be silently lost.

How Netdata helps

Per-second disk I/O metrics let you identify the actual lowest-I/O window for each drive, so you can schedule extended tests when they have the best chance of completing without contention.
Self-test result tracking in the SMART collector surfaces the abort pattern automatically, correlated with I/O load over the same period. Instead of manually checking logs, you see whether the drive was saturated at the time the test aborted.
System log monitoring surfaces link resets and SCSI error handler invocations that correlate with test aborts, providing the host-side context that SMART data alone cannot give.