badblocks: The Disk Test Its Own Manual Tells You Not to Run

badblocks is one of those tools people reach for when a disk starts behaving strangely. It is on almost every Linux system, it sounds exactly like what you want, and one of its options will wipe the drive you were trying to diagnose. The manual is unusually direct about all of this, so here is what it actually says.

What it does, and what it does not

The description is one line: badblocks searches a device for bad blocks. It produces a list.

That is the whole job. It does not repair anything. Sector reallocation is handled by the drive firmware on its own schedule, not by a userspace scanner. The list exists to be handed to e2fsck or mke2fs so the file system knows which blocks to leave alone.

This puts it in the same category as smartctl, which reports SMART attributes without repairing them either. Both tell you something. Neither fixes anything.

The option that erases your disk

Of everything here, this is the part to remember.

The -w flag runs a write-mode test. It writes the patterns 0xaa, 0x55, 0xff and 0x00 to every block on the device, reads each one back, and compares. It is a thorough test precisely because it uses the whole surface.

The manual carries an explicit warning:

Never use the -w option on a device containing an existing file system. This option erases data!

There is no undo, no partial preservation, no "it only overwrites the bad parts". Every block gets written.

The safe modes

By default, badblocks does a non-destructive read-only test. Running it with no mode flag reads the device and reports what it cannot read. Nothing is written.

The -n flag adds a non-destructive read-write test: it writes patterns but restores the original contents as it goes. The manual recommends it as the replacement for -w when a file system is present, and is honest about the trade: it is slower, but it will preserve your data.

-n and -w are mutually exclusive, which is a small mercy.

The recommendation almost nobody follows

Here is the part that surprises people who have used this tool for years. The manual says, in the description itself:

it is strongly recommended that users not run badblocks directly, but rather use the -c option of the e2fsck and mke2fs programs

The reason is block size. The block numbers badblocks produces depend on the block size the file system uses, and the default is 1024 bytes. If your file system uses something else and you did not pass -b, the numbers in your output do not refer to the blocks you think they do. Running the scan through e2fsck -c or mke2fs -c means the block size is correct by construction.

So the honest framing is: badblocks is a component, and the tools that call it usually know how to call it better than you do.

Why it refuses to touch a mounted device

badblocks will normally refuse a read/write or non-destructive test on a mounted device, because either can crash the system or damage the file system, even if it is mounted read-only.

There is a -f flag to override that refusal, and the manual's comment on it is one of the more memorable lines in a Linux man page:

This can be overridden using the -f flag, but should almost never be used --- if you think you're smarter than the badblocks program, you almost certainly aren't.

The correct move is to unmount the device. The manual allows exactly one exception, which is an /etc/mtab that wrongly claims a device is mounted.

The options worth knowing

A few flags change the shape of a run:

• -b sets the block size. Default 1024. This is the one that makes the output meaningful or meaningless.
• -c sets how many blocks are tested at a time. Default 64.
• -p repeats the scan until no new bad blocks appear in that many consecutive passes. Default 0, meaning a single pass.
• -e aborts after a given number of bad blocks. Useful for answering "are there any at all", and the manual notes it produces a possibly incomplete list, so do not use it when you want the full picture.
• -o writes the list to a file in the format e2fsck -l and mke2fs -l expect.
• -s shows progress, which matters because a full pass on a large disk is measured in hours.

When testing is the wrong move

This is the judgement call the manual cannot make for you.

A full badblocks pass reads, or reads and writes, every block on the device. On a healthy disk that is a long but harmless exercise. On a drive that is already failing, it is hours of additional load on hardware that is struggling, and hours during which you are not rescuing anything.

If the data still matters, the order is: image first, investigate second. Cloning with a tool designed for damaged media, which retries and skips intelligently rather than grinding on the same unreadable sector, gets your bytes off the disk while the disk still turns. We cover that in the guide on cloning a failing drive with ddrescue. Run your tests on the image afterwards, as many times as you like, with nothing left to lose.

The short version

badblocks searches for bad blocks and writes down what it finds. It repairs nothing.

The default mode is read-only and safe. -n writes and restores. -w erases the entire device, and the manual says never to use it where a file system exists. The manual also recommends not calling badblocks directly at all, but through e2fsck -c or mke2fs -c, so the block size is right. If it refuses to run because the device is mounted, unmount it rather than reaching for -f.

And if the drive is dying rather than merely suspect, do not spend its remaining hours testing it. Copy it first.

The behaviour described here, including the write-mode patterns, the warning against -w, the recommendation to use e2fsck and mke2fs rather than badblocks directly, the mounted-device refusal and the default values, is taken from the badblocks(8) manual page as shipped with e2fsprogs 1.47.0. Options and defaults can differ between versions; check the manual on the system you are actually using. Commercial links carry the rel="sponsored nofollow" attribute; an affiliate commission may apply at no extra cost to you.