disk-burnin.sh: a POSIX burn-in script that is safe by default

A burn-in script, and the one rule that governs it

disk-burnin.sh is a POSIX-compliant shell script for burn-in and testing of new or re-purposed drives, and the README is blunt about the rule that governs its use. The script runs `badblocks` in destructive mode, which erases any data on the disk, so it is intended only for disks that contain nothing, and the README asks you to be careful and not to run it on disks holding valuable data. The script must also be run as root, and the run time for large disks can be several days, which is why the README suggests using tmux or screen to test several disks in parallel. The author credits the FreeNAS forum thread on hard drive burn-in testing as the inspiration, which tells you where the sequence came from and who to thank for it. The design decision that makes the script usable is that the destructive path is opt-in, and the default mode is a dry run that performs no SMART test and invokes neither sleep nor badblocks.

Dry run first, and the flag that arms it

The dry-run mode exists so that you can check the plan before you commit a drive, and the README says exactly what it lets you check, the sleep durations and whether the sequence of commands suits your needs, and that in dry-run mode the script does not actually perform any SMART tests or invoke the `sleep` or `badblocks` programs. To actually test drives you have to provide the `-f` option, which the help text describes as running a full, destructive test and disabling the default dry-run mode, in bold capitals, with the warning that all data on the disk will be lost. The usage line is a conventional getopt style invocation, and the options are spelled out, with `-h` for help, `-e` for extended help, `-b` for the block size defaulting to 8192, `-c` for the number of concurrent blocks defaulting to 64 with a note that higher values use more memory, `-o` for the log directory defaulting to the working directory, `-p` for the number of consecutive passes defaulting to 0, and `-x` to perform a full pass of badblocks using the `-e 0` option. The examples section shows the three forms, a dry run on a disk, a destructive run on another, and a destructive run that writes its logs elsewhere.

The test sequence and how the SMART wait is timed

The tests are three steps in order, a SMART short test, then `badblocks`, then a SMART extended test. The interesting part is the waiting. The script calls `sleep` after starting each SMART test, using a duration based on the polling interval reported by the disk, after which it polls for test completion. So the script does not guess how long a drive needs, it reads the drive's own reported poll interval and derives the wait from it, which is the difference between a burn-in script that works on drives of different capacities and one that fails intermittently. Full SMART information is pulled after each SMART test, and the README notes that all output except for the `sleep` command is echoed to both the screen and the log file, which keeps the log a complete record of the run while not filling a terminal with a long countdown. The script also extracts the drive model and serial number and creates a log filename of the form `burnin-[model]_[serial number].log`, so a batch of drives produces a set of self identifying logs.

The four SMART attributes that decide the outcome

The README tells you what to watch while the burn-in runs, and it is a short list of SMART attributes rather than a general instruction to look for errors. The four to monitor are ID 5, Reallocated_Sector_Ct, ID 196, Reallocated_Event_Count, ID 197, Current_Pending_Sector, and ID 198, Offline_Uncorrectable. The README's guidance is that these indicate possible problems with the drive, so you may wish to abort the remaining tests and proceed with an RMA exchange for new drives or discard old ones. It also says the list is not exhaustive, which is the honest caveat, since a drive can develop a failure mode that is not in the table. The practical reading is that the script automates the procedure and the log capture, but the judgement call, whether to abort and replace a drive, stays with you. The `badblocks` errors are the other signal the README asks you to check, and the script's write mode makes those errors meaningful, since the drive is being written with real patterns rather than read.

What badblocks is told to do, and the four patterns it writes

The `badblocks` invocation is documented option by option, which is unusual and useful, because these are the parameters that decide how long the run takes and how much memory it uses. The block size is 8192, the number of concurrent blocks to check is 64, and the script aborts the test immediately when an error is found, with the note that the `-e` option overrides that. The number of consecutive scans without bad blocks required is 0, and the note is that a high value multiplies the execution time. Verbose mode is on, a list of bad blocks found is written to a file named `burnin-[model]_[serial number].bb`, progress is shown, and the write mode test is enabled, which writes four patterns, `0xaa`, `0x55`, `0xff` and `0x00`, on every block of the disk. Those four patterns are the reason the pass is a burn-in rather than a read, since each one is a pattern that a marginal controller or a marginal head can fail on, and writing all of them to every block is what shakes out a drive before it carries anything important.

Platform notes, the FreeBSD flag and the drives that were tried

The README has three platform sections that are worth reading before you run it. On FreeBSD and FreeNAS you must first run a sysctl command to alter the kernel's geometry debug flags, so that `badblocks` can write to the entire disk, and the README also says that `badblocks` may print a warning under those systems, `set_o_direct: Inappropiate ioctl for device`, which can safely be ignored because it has no effect on testing. Separately, some users with atypical hardware need to specify the `smartctl` device type explicitly with the `-d` option, and one user is credited with success using `-d sat` with a Western Digital MyBook 8TB external enclosure. The list of tested operating systems runs from FreeNAS 9.10.2-U1 and 11.1-U7 and 11.2-U8 through Ubuntu Server 16.04.2 LTS, CentOS 7.0, Tiny Core Linux 11.1 and Fedora 33 Workstation, and the drive list covers Intel, HGST, Western Digital and Seagate drives including several NAS oriented models, with the statement that the script should run successfully on any SAS or SATA disk with SMART capabilities.

The shape of the project and its maintenance state

The repository is deliberately small. There is a `disk-burnin.sh`, a `license.txt`, a README, an editor configuration and one example log file, `burnin-SAMSUNG_HD204UI_XXXXXXXXXXXXXX.log`, which is a nice touch because it shows you the shape of the output before you run anything. The prerequisites section names smartmontools as the package to install and lists the external programs the script relies on, `grep`, `awk`, `sed`, `sleep`, `badblocks` and `smartctl`, and it says the script was tested with the static analysis tool shellcheck to make sure the code is POSIX compliant and free of issues, which is a reasonable standard for a script that has to run on FreeNAS, CentOS and Tiny Core alike. The authorship note is worth reading because it dates the code, with the original author named as Keith Nash in March 2017 and the script modified on 19 February 2021. The single tagged release is 1.1.0 from April 2021, while the last push to the branch was on 2026-07-29, so the script is being touched without a new release, and it is a script rather than a package, so there is nothing to install.

Editorial conclusion

Adopt disk-burnin.sh if you are qualifying new drives or second-hand disks before they carry data, and you want the standard SMART short, badblocks, SMART extended sequence in one auditable script with a log per drive. Do not run it on a disk that holds anything you want, since the badblocks pass is destructive and the README says so in bold, and read the FreeBSD note before you use it on FreeNAS, because the kernel geometry flag has to be changed for badblocks to reach the whole disk. Before you start, run it in the default dry-run mode to check the timing the script computed, because the sleep durations come from the drive's own reported polling interval and a large disk can take days. The licence is a custom one GitHub cannot classify, the single release is 1.1.0 from 2021-04-28, and the last push was on 2026-07-29.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. Spearfoot/disk-burnin-and-testing on GitHub