Quick Start Guide
This guide will walk you through the essential steps to test a disk using disk-burnin.sh
.
Prerequisites: You must be running as the root
user to execute this script, as it requires low-level disk access.
Step 1: Identify Your Target Disk
Before running the script, you must correctly identify the device name of the disk you want to test. Use tools like lsblk
, fdisk -l
, or smartctl --scan
to list the available drives. Be extremely careful to select the correct one.
# Example using lsblk
lsblk
# NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
# sda 8:0 0 238.5G 0 disk
# ├─sda1 8:1 0 512M 0 part /boot/efi
# └─sda2 8:2 0 238G 0 part /
# sdb 8:16 0 1.8T 0 disk <-- This is our target disk
# sdc 8:32 0 1.8T 0 disk
In this example, /dev/sdb
is the new, empty disk we want to test.
Step 2: Perform a Dry Run (Safety Check)
By default, the script runs in dry-run mode. This is a safety feature that prints the commands it would run without actually executing them. This is the recommended first step to ensure you've targeted the correct disk and the parameters are as you expect.
# The script must be run with root privileges
sudo ./disk-burnin.sh sdb
You can specify the disk with or without the /dev/
prefix (sdb
or /dev/sdb
).
The output will show you the exact smartctl
and badblocks
commands that will be run, along with the calculated test durations. You will see lines prefixed with DRY RUN:
.
[...]
DRY RUN: smartctl --test="short" "/dev/sdb"
SMART short test started, awaiting completion for 120 seconds ...
DRY RUN: sleep "120"
DRY RUN: poll_selftest_complete
[...]
DRY RUN: badblocks -b 8192 -wsv -c 64 -e 1 -o "./burnin-SAMSUNG_HD204UI_XXXXXXXXXXXXXX.bb" "/dev/sdb"
[...]
Review this output carefully.
Step 3: Run the Destructive Test
Once you have confirmed that the dry run looks correct, you can proceed with the actual destructive test. To do this, you must add the -f
(force) flag.
WARNING: This step will permanently erase all data on the specified disk. Double-check your disk name one last time.
# Run the full destructive test on /dev/sdb
sudo ./disk-burnin.sh -f sdb
The script will now execute the tests. This process can take a very long time—from several hours to multiple days, depending on the size and speed of the drive.
For long-running sessions, it is highly recommended to use a terminal multiplexer like screen
or tmux
to prevent the process from being terminated if your SSH connection drops.
# Using tmux
tmux new -s burnin_sdb
sudo ./disk-burnin.sh -f sdb
# You can now safely detach (Ctrl+b, d) and re-attach (tmux attach -t burnin_sdb)
Step 4: Monitor and Check Results
The script will print its progress to the console and simultaneously write to a log file in the current directory (or the directory specified with -o
).
The log file will be named burnin-[model]_[serial number].log
.
# Monitor the log file in real-time
tail -f burnin-SAMSUNG_HD204UI_XXXXXXXXXXXXXX.log
If badblocks
finds any errors, it will stop (by default) and log them to a file named burnin-[model]_[serial number].bb
.
After the script completes, review the final log file for any SMART errors or test failures.