badblocks

badblocks is a program to test storage devices for bad blocks.

S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology) is featured in almost every HDD still in use nowadays, and in some cases it can automatically retire defective HDD sectors. However, S.M.A.R.T. only passively waits for errors while badblocks can actively write simple patterns to every block of a device and then check them, searching for damaged areas (Just like memtest86* does with RAM).

This can be done in a destructive write-mode that effectively wipes the device (do backup!) or in non-destructive read-write (backup advisable as well!) and read-only modes.

Installation

Install the e2fsprogs package.

See badblocks(8) for the usage.

Storage device fidelity

Although there is no firm rule, it is common thinking that a new drive should have zero bad sectors. Over time, bad sectors will develop and although they are able to be defined to the file system so that they are avoided, continual use of the drive will usually result in additional bad sectors forming and it is usually the harbinger of its eventual death. Replacing the device is recommended.

Comparisons with other programs

Typical recommended practice for testing a storage device for bad sectors is to use the manufacturer's testing program. Most manufacturers have programs that do this. The main reasoning for this is that manufacturers usually have their standards built into the test programs that will tell you if the drive needs to be replaced or not. The caveat here being is that some manufacturers testing programs do not print full test results and allow a certain number of bad sectors saying only if they pass or not. Manufacturer programs, however, are generally quicker than badblocks sometimes a fair amount so.

Testing for bad sectors

To test for bad sectors in Linux, the program badblocks is typically used. badblocks has several different modes to be able to detect bad sectors.

Read-write test (warning: destructive)

This test is primarily for testing new drives and is a read-write test. As the pattern is written to every accessible block, the device effectively gets wiped. 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. ( as the root user)
: run through the extensive four pass test number of sequent iterations
: print bad sectors to output-file instead of stdout
: 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 [...]."

Random pattern

Badblocks can be made to repeatedly write a single "random pattern" with the 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)

Read-write test (non-destructive)

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.

The 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 (). 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 option tells run in non-destructive test mode, the -v tells to show its output, and the 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 option, bad sectors will only be printed to stdout.

Example output for read errors in the beginning of the disk:

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:

# mkfs.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 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 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 to do a read-write bad block test.

Block size

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 being the drive letter and 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 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.

After all this, you should have the block number(s) of your bad block(s), relative to the partition they exist on.

Alternatives

Since badblocks was originally written to verify floppy disks, its design isn’t construed for modern HDD drives. With sizes such as 18 TB drives, even the regular tip to use -b 4096 won’t help anymore. This is an 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.

gollark: <@!356209633313947648> That sounds like a *terrible* way to secure anything.
gollark: What about it?
gollark: What?
gollark: You know, my server ran on a RPi for ages. It was always nginx-based, though.
gollark: https://www.nginx.com/resources/wiki/start/topics/examples/likeapache-htaccess/
This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.