Short Test, Long Test, and Scrubs
What each actually checks, and how often to run them.
01Your drive has a built-in health check — and you're probably not running it
Most drives that ship modern firmware include an internal self-test routine baked into the SMART layer. Plug the drive into a diagnostic tool and you'll see two options: a Short test and an Extended (Long) test. They sound like the same thing at different speeds. They are not.
The Short test takes between one and two minutes and covers a focused set of checks: the drive's electronic circuitry, a read scan of a small sample of sectors, and a quick verification of basic mechanical functions — head positioning, spin speed, servo response. It runs entirely inside the drive, using its own firmware routines and calibration data. Because it samples rather than sweeps, it can miss a developing problem sitting in a corner of the disk the test never visited. Pass means "nothing obviously wrong right now." It does not mean clean.
The Extended test — sometimes labelled Long in diagnostic utilities — runs a complete surface scan, reading every sector in sequence and verifying the data can be retrieved correctly. On a large spinning drive this can take several hours; on a smaller or solid-state drive it runs faster, though the definition of "complete scan" differs by firmware. Where the Short test is a temperature check, the Extended test is a physical examination. Any sector that resists reading cleanly will show up as a pending reallocation: the drive flags it and, if the sector can be written to successfully, moves the data to a spare block drawn from the pool of reserved capacity. That process — and those two counters — are worth watching closely.
Run the Short test weekly on drives that hold anything you'd miss. Run the Extended test monthly, or immediately any time you hear something odd, or if SMART starts reporting values you haven't seen before. Scheduling matters more than the exact interval: a test you run consistently will catch deterioration across time; a test you run once, when you're already worried, tells you only what is true at that moment. Both tests write a result code to the SMART log — pass, fail, or aborted — so checking the log is as important as scheduling the test.
Run the Short test weekly on drives that hold anything you'd miss.
02Scrubs are different, and they catch something self-tests miss
A scrub is not a SMART operation. It lives in the file system, not the drive firmware, and it does something neither the Short nor Extended test can: it reads data, recomputes its checksum, and compares the result against the stored value. A sector that returns its bytes without triggering a drive-level read error but delivers corrupted data — a condition called a silent data error, or bit rot — will sail through both SMART tests and only surface during a scrub.
ZFS and Btrfs both implement scrubbing natively. ZFS checksums every data and metadata block at write time and re-verifies every block at scrub time; if it finds a mismatch and a redundant copy exists (a mirror or RAIDZ pool), it repairs silently and logs the event. Btrfs operates similarly, though its scrub implementation and repair path are less battle-tested. On ext4, NTFS, or APFS — file systems that do not checksum data blocks — there is no equivalent operation: those file systems cannot detect silent corruption at rest.
Monthly scrubs are a reasonable baseline for ZFS pools under normal workloads. Pools on always-on hardware can run them on a cron schedule with minimal impact during off-peak hours. The scrub log will show you how many blocks were read, how many errors were found, and whether any were repaired. An error count rising between scrubs is a signal worth acting on; a consistent zero across many months is reassuring evidence that storage is behaving.
Taken together, these three routines — weekly Short tests, monthly Extended tests, monthly scrubs where your file system supports them — form the active monitoring layer that sits between silent failure and the moment you notice data is missing. They are not a substitute for backup, and a pass result is not a guarantee. But they are how a drive problem announces itself with enough lead time to act.
| Test | What it checks | Rough duration |
|---|---|---|
| Short self-test | Electrical and mechanical checks plus a sample of the surface | Minutes |
| Extended / long self-test | A full read of the entire recording surface | Hours, scaling with capacity |
| Conveyance test | Whether damage occurred in transport | Minutes |
| Filesystem scrub (ZFS, Btrfs) | Every block against its stored checksum, repairing from redundancy | Hours, and it runs online |
| RAID patrol read / consistency check | Every sector of every member, and parity agreement | Hours to days |
A passing short test is not good news; it is the absence of news. A long test that stops at a read error has told you exactly where to stop trusting the disk.