Scan a Disk for Bad Blocks with badblocks

A drive that stalls, clicks or throws odd read errors is exactly when you reach for badblocks, and the read-only mode is the one to run first. You will finish with a read-only scan of a chosen device, a clear read on the result, and an optional bad-block list you can hand to e2fsck or mke2fs. The examples use badblocks from e2fsprogs 1.47.0. Allow minutes to hours for a real disk: duration depends on its size, speed and errors.

Before you start

• You need: a Linux shell and the badblocks command.
• Privilege: scanning a real block device normally needs elevated rights, so use sudo where shown.
• Get the device name right. A wrong device is not a harmless typo once you pick a write test or later feed a bad-block list into a repair.

First, identify the target without changing anything:

lsblk --output NAME,SIZE,FSTYPE,MOUNTPOINTS
sudo blkid /dev/DEVICE

Replace /dev/DEVICE with a real partition or disk, such as /dev/sdb1. Check the size, file-system type and mount point against your notes. If the device holds valuable data, make a tested backup before investigating hardware faults.

Checkpoint: do not continue until the path names the intended device. A mounted file system is not automatically safe just because the scan is read-only.

Run the safe first scan

sudo badblocks -sv /dev/DEVICE

• What this mode does. badblocks reads blocks and reports those that could not be read.
• Defaults: block size 1024 bytes, 64 blocks checked at a time, one pass.
• -s shows rough percentage progress; -v reports read errors, write errors and data corruption counts.

A clean scan ends with output similar to this:

Checking blocks 0 to 255
Checking for bad blocks (read-only test): ... done
Pass completed, 0 bad blocks found. (0/0/0 errors)

The exact range and progress display vary with the device. Any reported bad block is a reason to treat the storage and its backup history seriously. A clean scan is useful evidence, not a guarantee the disk stays healthy.

To record the result for later use, add an output file:

sudo badblocks -sv -o /root/DEVICE.badblocks /dev/DEVICE

The file contains block numbers suitable for the -l option of e2fsck or mke2fs. Keep the block size consistent with the file system that will consume the list. The manpage recommends the -c option of those tools instead of running badblocks directly, when that is the real job, because they already know the file system block size.

Use the right block size

Block numbers depend on -b. The badblocks default is 1024 bytes, but an ext file system may use another size. Find the file system block size before producing a list for it:

sudo tune2fs -l /dev/DEVICE | grep '^Block size:'

Then scan with the reported number, for example:

sudo badblocks -sv -b 4096 -o /root/DEVICE.badblocks /dev/DEVICE

If the device is not an ext file system, do not assume this command or its output is the correct repair workflow: consult the tools for that file system instead. For ext file systems, prefer the file-system-aware checks where possible; a raw list with the wrong block size can point at the wrong locations.

Checkpoint: the output file and the file-system metadata must describe the same device and block size. If either is uncertain, stop and repeat identification rather than applying the list.

Understand the modes that write

• -n is a non-destructive read-write test. It writes and reads patterns while attempting to preserve existing data. Slower, and still needs an unmounted device: do not use it casually on a live file system.

Destructive warning: -w writes the patterns 0xaa, 0x55, 0xff and 0x00 to every tested block. This erases data. Never use it on a device containing an existing file system or anything you need to keep. There is no badblocks undo; recovery would depend on backups or specialist data recovery.

The program normally refuses a read-write or non-destructive test on a mounted device. Do not bypass that protection with -f merely to make a command run: the manpage describes that override as almost never appropriate because it can crash the system or damage the file system, even when the mount is read-only. Unmount the intended device first, using the mount point you confirmed earlier:

sudo umount /mount/point
sudo badblocks -sv -n /dev/DEVICE

Unmounting changes system state and can disrupt applications using the file system. If umount reports the target is busy, find and stop the processes using it; do not force the bad-block test over the mount. Afterward, remount it only once you have finished the check:

sudo mount /dev/DEVICE /mount/point

Use a numeric -t pattern only when you understand what was previously written. In read-only mode the pattern must not be random and assumes the same pattern already exists on the device; otherwise many ordinary blocks can appear to fail verification.

Common traps and stopping safely

• Wrong target. A partition such as /dev/sdb1 is not the same thing as its whole disk, /dev/sdb. Recheck lsblk before every run.
• Incomplete list. -e MAX_BAD_BLOCKS stops after that many bad blocks, so its output can be incomplete: not suitable when you need the full list.
• Unexpected duration. -p PASSES repeats scanning until the requested number of consecutive passes find no new blocks. The default is one pass; drop it for an initial assessment only.
• Interrupted scan. Press Ctrl-C to stop a read-only scan and treat any partial output as incomplete. If a non-destructive test is taking too long, stopping avoids continuing writes, but it does not replace a finished check.

For a deliberately small, harmless syntax check, a regular temporary file can be scanned without touching a disk device:

truncate -s 1M /tmp/badblocks-test.img
badblocks -sv -b 4096 /tmp/badblocks-test.img

That only tests the temporary file's allocated blocks. It says nothing about the physical storage underneath it, so it is not a disk health test.

Done means

• Target confirmed: you checked the exact device with lsblk and its mount state.
• Read-only scan first: you ran the default test before considering any write mode.
• Correct block size: you used the file system's block size when producing a list for another tool.
• Write modes respected: -n treated as a mounted-device risk, -w as data-erasing.
• Result understood: you know whether the output is a complete scan or only a partial result.