SMART drive health on Linux: warnings, self-tests and limits

Use SMART to choose the next action, not to certify that a drive or its files are safe. First establish which device and reporting path were queried. Then distinguish an actual device warning from an unsupported command, and distinguish a completed self-test from a request to start one.

If important data is already at risk, preserving a surviving copy takes priority over optional diagnostic work. A green summary should not override a specific warning, a read failure or an unresolved access problem.

Research guide: drive-health guidance comes from smartmontools, drive makers and NVMe documentation.

If the next action is buying replacement NAS disks, use our NAS hard-drive comparison to match the exact CMR model, capacity and warranty before ordering. A vendor reliability rating does not replace checking the delivered drive or preserving a recoverable copy.

Checking a drive through USB? Start with the which smartctl -d flag table for SAT and USB-NVMe bridges. The same guide compares docks and shows how to take a working check into Scrutiny and Home Assistant.

Choose the next action before running another test

SMART is a device-reporting and diagnostic tool, not a replacement for a recovery plan. Start by deciding whether you are checking an expendable candidate drive, monitoring a working system or investigating threatened data. Those situations should not trigger the same automatic sequence of tests.

Seagate’s SMART warning guidance notes that a drive can appear to work normally and some diagnostics can still pass despite a warning. It advises preserving data promptly. Treat a warning as something to investigate with the exact vendor guidance, rather than waiting for every tool to agree.

For a drive holding the only accessible copy, establish the recovery route before optional extended tests. If data cannot be read normally, repeated testing is not a recovery method. Get appropriate recovery advice rather than improvising repair operations on the original.

Observation	Next action	Conclusion to avoid
Tool cannot open or query the intended device	Verify identity, permissions and supported reporting path	The drive passed, or the drive necessarily failed
Device reports a health warning	Preserve data and follow the exact vendor’s diagnostic/service guidance	Another PASS cancels the warning
Successful query reports no warning	Preserve the report and check the required diagnostic scope	The drive cannot fail later
Self-test was started or remains in progress	Record the request and inspect its eventual result	The command succeeded, therefore the test passed
Test was interrupted, aborted or unsupported	Record that status and resolve what can be tested	No completed failure means a completed pass
A completed supported test reports an error	Preserve its details and investigate under vendor guidance	The tool has repaired the underlying problem
Files or an application fail verification	Investigate the relevant storage and recovery layers	A clean device summary proves the files are correct

Identify the device and the path used to reach it

Create a private inventory before capturing reports: model, firmware, interface, selected device path, controller or enclosure, operating-system version and diagnostic-tool version. Record whether the report concerns the physical drive, an NVMe controller or namespace, or a logical device exposed by a controller.

Keep enough identity information to avoid comparing different devices across captures. A convenient operating-system name alone should not be treated as permanent identity when hardware or attachment changes. There is no reason to publish serial numbers, enclosure identifiers or a real system layout in an example.

The used enterprise hardware guide explains how to resolve product identity, firmware and accessory questions before accepting equipment. Apply that discipline to storage included with a used system too. A machine booting successfully is not the diagnostic record you still need.

Define what the reporting path must reveal. If the requirement is individual member-drive health, verify that the chosen tool and controller actually expose those members. A logical-volume status page should not silently stand in for the missing device observations.

Capture a baseline before changing anything

The smartmontools manual published by Debian documents device discovery and extended information queries. Check the manual installed with your tool before using options, especially through controllers or bridges.

The following examples use the literal placeholder DEVICE. Replace it only after verifying the intended target and the appropriate device type.

smartctl --version
sudo smartctl --scan
sudo smartctl -x DEVICE

Save the full response, timestamp and command completion status in the private diagnostic record. Preserve warnings about unsupported information too. An attractive summary copied without its surrounding errors loses information needed to interpret it.

The report should answer whether the intended device was queried successfully, which fields were available and which additional evidence is still required. Do not enable unrelated features, clear logs or change firmware merely to make the initial report look more complete.

Read ATA attributes in the exact vendor’s context

ATA SMART attributes can contain raw and normalised values with vendor-specific interpretation. The manual does not define every raw field as a common physical measurement. Read the model’s documentation rather than treating a large raw number or a familiar attribute name as a universal replacement threshold.

For the private record, keep the attribute identifier, displayed name, raw value, normalised value, threshold and any failure indication together where provided. Preserve the units and decoding assumptions supplied by the relevant documentation. A screenshot of a single column is an incomplete comparison.

If a value changes, first confirm that the captures concern the same drive and that the reporting or decoding method has not changed. Then investigate the change in the context of device warnings and observed symptoms. Do not turn an unexplained difference into a made-up remaining-life estimate.

There is no generic counter value in this guide that automatically means “keep” or “replace.” The decision should name the documented condition and the action that condition requires.

Read NVMe indicators as separate observations

NVM Express’s health and error-reporting overview separates critical warnings, media or data-integrity error information, unsafe shutdowns and endurance indicators such as Percentage Used. Those labels answer different questions.

Start with the actual warning condition reported by the device and decode it using the applicable documentation. Do not hide a warning behind an endurance gauge that appears reassuring. Likewise, an endurance indicator should not be translated into a guaranteed calendar lifetime.

Keep historical counters beside their capture time and operating context. An unsafe-shutdown entry needs investigation, but it is not by itself proof that the media currently contains an unreadable file. Retain enough information to compare later observations without pretending that every field measures the same kind of health.

When a report is scoped to a controller or namespace, record that scope explicitly. Avoid expanding a limited observation into a claim that every part of a larger storage configuration was checked.

Choose a supported self-test and read its result

A request to start a self-test and a completed result are separate records. For an intended short self-test, first confirm that the installed tool, device and reporting path support the operation. Consult the exact instructions rather than assuming identical behaviour for ATA, SCSI and NVMe.

For a supported target, the smartmontools workflow distinguishes starting the test from reading its log:

sudo smartctl -t short DEVICE
sudo smartctl -l selftest DEVICE

Wait for the reported completion time, then identify the new test entry and its status. An older completed test is different evidence from the current request.

Plan around the documented operating impact. Self-tests can affect workload performance, and activity can affect completion time. Avoid captive or forced modes as a shortcut around unresolved support.

Record why the chosen test fits the acceptance question. If a longer test is required, use the supported procedure and preserve its actual completion status. Starting additional tests until one appears reassuring is not a substitute for explaining a previous error.

Treat an inaccessible report as an unresolved check

Seagate’s openSeaChest health-check documentation explicitly distinguishes an unable-to-check result from drive health. The failed operation might concern access or support rather than a completed device assessment.

Work through the reporting path deliberately. Confirm the selected target, necessary privileges, installed tool support and controller or enclosure documentation. If a device-type option is required, use the documented choice for that exact arrangement; do not cycle through unsupported pass-through modes on important data.

Preserve the error message and record what remains unseen. If changing the attachment is an appropriate supported diagnostic step, capture a separate before-and-after record. A report through another path can help resolve visibility, but it does not retroactively turn the earlier failed query into a pass.

This distinction matters for automation too. The smartctl exit status is a bitmask, so retain its meaning and diagnostic output rather than mapping every nonzero result to one “bad disk” alert. Follow the installed manual’s definitions for the protocol being used.

Preserve trends without inventing a failure forecast

A useful monitoring record is a sequence of comparable observations. Keep capture times, device identity, firmware, tool version, report scope and full warnings alongside values. Make any change in decoding or connection path visible.

Define what will trigger investigation according to the exact device documentation and the operational requirement. Examples include a newly reported warning or a new failed completed test, rather than an invented universal raw-value limit.

Also define who will notice an alert and what evidence they need to act. A monitoring process that saves a report but provides no usable response path leaves the acceptance question unfinished.

Do not erase history to obtain a green baseline. If logs or counters reset as part of a supported change, record the change and the resulting comparison limit. A missing history is not evidence that nothing happened.

Keep an acceptance record with explicit limits

Keep a simple record you can compare the next time you check the drive.

Record	Preserve	Limit to keep visible
Identity and reporting path	Model, firmware, interface, controller/enclosure and selected scope	Unseen members remain unverified
Baseline capture	Tool version, timestamp, full output and command status	Missing fields are not healthy values
Warning assessment	Exact reported condition and vendor interpretation	A separate PASS does not cancel it
Self-test record	Requested test, support, progress and completed log entry	Started, aborted and completed are different states
Comparison history	Comparable captures and configuration changes	A trend is not a failure-date forecast
Recovery evidence	Surviving copy and a separate file/application restoration check	Device diagnostics do not prove recoverability

For an acceptance decision, write down unresolved items as well as successful observations. A used-drive return window, for example, is a reason to settle a visibility problem promptly, not a reason to relabel an incomplete check as success.

Keep device health separate from storage correctness

A drive report, a pool or array status and a filesystem integrity result belong to different layers. The ZFS, mdadm and hardware RAID guide explains those ownership boundaries. Preserve the relevant evidence from each layer when investigating a storage problem.

The RAID, snapshots and backups guide covers surviving copies and restoration. A completed device self-test does not demonstrate that an application can recover the files it needs.

Use the result to pick a clear next step: back up, resolve missing data, investigate a warning or read a completed test. Keep the report so your next check has something useful to compare.

If a replacement purchase is the next step, the NVMe boot-drive comparison compares the SN570 with two SN5100 options, including exact-model fit and capacity. Use drive diagnostics to assess the existing device before deciding what to replace.