badblocks

Related articles
Identify damaged files
badblocks
is a program to test storage devices for bad blocks.
Modern HDDs and SSDs include firmware that will automatically detect, attempt to correct, and report errors. However, firmware becomes aware of a corrupted sector only upon an attempt to read or write to it.
Badblocks
may be used to test the entire device at once. It operates by sequentially attempting to read and optionally write to and read back every sector on a drive, and report errors. Consequently, the firmware will react to any detected failures in this process.
Installation
Install
the
e2fsprogs
package.
See
badblocks(8)
for the usage.
Storage device fidelity
Due to natural manufacturing defects, every new drive generally has some bad sectors. However as part of manufacturing these sectors are scanned for, detected, and reported to the firmware of the drive. Sectors such as this will not be visible to end users, a new drive should always report zero bad sectors. As part of normal usage, drives will degrade over time developing more bad sectors. Drive firmware automatically monitors and attempts to correct for this and a small number of bad blocks on older drives is expected. An increasing number of bad blocks generally indicates a failing drive, and more than a few on a drive still within warranty generally indicates a defective drive, both of which should be replaced.
Comparisons with other programs
Many storage device manufacturers have their own test programs for drives. Their standards as well as firmware specific quirks are normally built in to the program, and can be more accurate for drive health than
badblocks
. Furthermore, they can take much less time to scan drive than
badblocks
. However, some tools do not always report full tests results and simply report a pass or failure, making them less useful for precise information.
Testing
Read-only test
Read-only tests attempt to read every single sector on the specified drive. The operation is non-destructive and may be safely executed on live systems. It is similar to an
extended S.M.A.R.T. self-test
, however unlike the self-test
badblocks
will proceed even after encountering an error, identifying all errors on the device.
Write-mode test
Warning
Write-mode bad blocks tests are destructive to
all
data on the drive upon which they are executed, and data cannot be recovered. The test will begin as soon as the command is executed, there is no backout period or confirmation. Double check what drive you are targeting before executing any write-mode command.
Write tests are a more intensive but fully destructive test, in which a pattern is written to the entire disk and then read back after a pass. As the pattern is written to every accessible block, contents of the device are lost. The default is an extensive test with four passes using four different patterns: 0xaa (10101010), 0x55 (01010101), 0xff (11111111) and 0x00 (00000000). For some devices this will take a couple of days to complete.
# badblocks -wsv /dev/
device
Checking for bad blocks in read-write mode
From block 0 to 488386583
Testing with pattern
0xaa
: done
Reading and comparing: done
Testing with pattern
0x55
: done
Reading and comparing: done
Testing with pattern
0xff
: 22.93% done, 4:09:55 elapsed. (0/0/0 errors)
[...]
Testing with pattern
0x00
: done
Reading and comparing: done
Pass completed, 0 bad blocks found. (0/0/0 errors)
Options:
-w
: do a destructive write test
-s
: show progress
-v
: be "verbose" and output bad sectors detected to stdout
Additional options you might consider:
-b
number
: specify the block size of the hard disk which can significantly improve testing time. (
tune2fs -l
partition
| grep 'Block size'
as the root user). For drives larger than two terabytes,
-b 4096
is required for the test to proceed properly
-p
number
: run through the extensive four pass test
number
of sequent iterations
-o
/path/to/output-file
: print bad sectors to
output-file
instead of stdout
-t
test_pattern
: Specify a pattern. See below.
Define specific test pattern
From the manpage:
"The
test_pattern
may either be a numeric value between 0 and  ULONG_MAX-1  inclusive [...]."
This article or section needs expansion.
Reason:
please use the first argument of the template to provide a brief explanation.
(Discuss in
Talk:Badblocks
)
Random pattern
Badblocks
can be made to repeatedly write a single "random pattern" with the
-t random
option.
# badblocks -wsv -t random /dev/
device
Checking for bad blocks in read-write mode
From block 0 to 488386583
Testing with
random pattern
: done                                                 
Reading and comparing: done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)
Note
The random generator is not suitable for cryptographic purposes.
Badblocks
should not be used e.g. for
block device encryption
.
Read-write test (non-destructive)
Warning
This test should not be performed on mounted file systems or if anything else may be writing to the tested area while badblocks is running. This may lead to data loss.
This test is designed for devices with data already on them. A non-destructive read-write test makes a backup of the original content of a sector before testing with a single random pattern and then restoring the content from the backup. This is a single pass test and is useful as a general maintenance test.
# badblocks -nsv /dev/
device
Checking for bad blocks in non-destructive read-write mode
From block 0 to 488386583
Checking for bad blocks (non-destructive read-write test)
Testing with
random pattern
: done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)
The
-n
option signifies a non-destructive read-write test.
Have filesystem incorporate bad sectors
To not use bad sectors, they have to be known by the filesystem.
During filesystem check
Incorporating bad sectors can be done using the filesystem check utility (
fsck
).
fsck
can be told to use
badblocks
during a check.  To do a
read-write
(non-destructive) test and have the bad sectors made known to the filesystem, run:
# fsck -vcck /dev/
device-PARTITION
The
-cc
option tells run
fsck
in
non-destructive
test mode, the
-v
tells
fsck
to show its output, and the
-k
option preserves old bad sectors that were detected.
To do a
read-only
test (not recommended):
# fsck -vck /dev/
device-PARTITION
Before filesystem creation
Alternately, this can be done before filesystem creation.
If
badblocks
is run without the
-o
option, bad sectors will only be printed to stdout.
Example output for read errors in the beginning of the disk:
# badblocks -wsv /dev/
drive
[...]
Testing with pattern
0xff
: done                                                 
Reading and comparing:
[...]
37584
37585 0.84% done, 7:31:08 elapsed. (0/0/527405 errors)
37586
[...]
done
Testing with pattern
0x00
:
Reading and comparing:
[...]
37584
37585
[...]
done
Pass completed, 527405 bad blocks found. (0/0/527405 errors)
For comfortably passing
badblocks
error output to the filesystem, it has to be written to a file.
# badblocks -wsv
-o
/root/
badblocks.txt
/dev/
device
Checking for bad blocks in read-write mode
From block 0 to 488386583
Testing with pattern
0xaa
: done
Reading and comparing:   6.36% done, 0:51 elapsed. (0/0/14713 errors)
[...]
Testing with pattern
0x00
: done
Reading and comparing: done
Pass completed, 527405 bad blocks found. (0/0/527405 errors)
Then (re-)create the file system with the information:
# mke2fs -t
filesystem-type
-l
/root/
badblocks.txt
/dev/
device
Note
The meaning of
0/0/527405
errors is
number_of_read_errors
/
number_of_write_errors
/
number_of_corruption_errors
.
Ext4
From the
mke2fs(8)
manual page:
Note that the block numbers in the bad block list must be generated using the same block size as used by
mke2fs
. As a result, the
-c
option to
mke2fs
is a much simpler and less error-prone method of checking a disk for bad blocks before formatting it.
So the recommended method is to use:
# mkfs.ext4 -c /dev/
device
Use
-cc
to do a read-write bad block test.
Block size
This article or section is a candidate for merging with
Securely wipe disk#Block size
.
Notes:
Block size alignment is not specific to this tiny section. Other Arch Wiki Articles already do cover this up. Search for it and cover everything up on a
Block size
page. (Discuss in
Talk:Badblocks
)
First, find the file systems'
block size
.  For example for ext# filesystems:
# dumpe2fs /dev/
device-PARTITION
| grep 'Block size'
Feed this to
badblocks
:
# badblocks -b
block size
Finding bad sectors
You can use badblock to find bad sectors. Note that
badblocks
calls sectors "blocks". It supports a few scan modes. There is read-only mode (default) which is the least accurate. There is the destructive write-mode (
-w
option) which is the most accurate but takes longer and will (obviously) destroy all data on the drive, thus making it quite useless for matching sectors up to files. There is finally the non-destructive read-write mode which is probably as accurate as the destructive mode, with the only real downside that it is probably the slowest. However, if a drive is known to be failing, then read-only mode is probably still the safest.
To do a verbose (
-v
option), read-only scan, run one of these commands (with
x
being the drive letter and
y
being partition number you want to scan):
Whole disk scan:
# badblocks -v /dev/sdx
Single partition scan:
# badblocks -v /dev/sdxy
The downside to scanning the drive as a whole is that each filesystem is going to start its block count relative to the partition it is on. This means that if you have a bad block that happens to be on, let us say, the second partition, and that partition starts on block 1000, then you will have to subtract 1000 from your block number in order to get the number you want. So if a scan from the beginning of the disk results in block number 1005 being bad, then block 5 of the second partition is what you will actually be using.
Otherwise, if you have found bad blocks after doing a full scan, you can simply figure out which partitions they are on, and rescan those in order to get the block number, rather than do any block math.
Another thing to note is that
badblocks
defaults to 1024 byte blocks, so you will either have to change the default size with the
-b
option in order to match your filesystem or manually convert the block number(s) later.
If you need to figure out where your partitions start and end, run
fdisk
. Make sure to note the block size
fdisk
is using so that you can convert the block counts to match your scan.
# fdisk -l /dev/sdx
Disk /dev/sdx: 149.05 GiB, 160041885696 bytes, 312581808 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
After all this, you should have the block number(s) of your bad block(s), relative to the partition they exist on.
Interaction with remapping
HDD controllers with SMART are generally able to remap a bad sector. They still waste time retrying reads at a bad sector, but on a write they either manage to fix it (when the error is "soft", i.e. ECC failure) or remap it to a spare sector, as long as the spare is not depleted.
In non-destructive RW mode, badblocks first attempt a read of a sector. As a result, both "soft" and "hard" bad sectors are considered bad and not further tested. You should see the pending count unchanged or go up in SMART.
In destructive RW mode, badblocks does the writing first. As a result, a remap should be triggered and the sector should be "fixed" in terms of being accessible. You should see the pending sector count go down in SMART, while the reallocated count stays unchanged (if "soft") or goes up (if "hard"). badblocks will go on to test whether the sector faithfully retains the data, as it is originally designed to.
It is possible to force a write using the badblocks list from non-destructive testing. One would need to calculate the LBA ranges, use
hdparm --read-sector
to narrow it down to single sectors, and finally use
hdparm --write-sector
[1]
to trigger the write. You would be giving up on any possible future retries at this sector, but at least no more read hangs would occur.
Alternatives
Since
badblocks
was originally written to verify floppy disks, its design is not construed for modern HDDs. With sizes such as 18 TB drives, even the regular tip to use
-b 4096
will not help anymore
. Encrypting a bunch of zeroes is a great alternative:
Span a crypto layer above the device:
cryptsetup open /dev/
device
name
--type plain --cipher aes-xts-plain64
Fill the now opened decrypted layer with zeroes, which get written as encrypted data:
shred -v -n 0 -z /dev/mapper/
name
Compare fresh zeroes with the decrypted layer:
cmp -b /dev/zero /dev/mapper/
name
If it just stops with a message about end of file, the drive is fine. This method is also way faster than
badblocks
even with a single pass. As the command does a full write, any bad sectors (as known to the disk controller) should also be eliminated.
On btrfs and ZFS, the designers have decided that a floppy-era bad block list is not needed any more. They are usually right as long as you write over the defects (see above). Reading will still hang from retrying. If you want to "isolate" the bad blocks like in the old days, use a lower-level solution by partitioning or LVM.
On modern spinning drives,
smartctl -t long /dev/
device
(see
S.M.A.R.T.
) performs a full read-only test. It will halt as soon as a failure is found and record it as a "LBA_of_first_error" data entry, which you can then overwrite with hdparm (see above). You can skip the failure with a follow up selective test.