3

It has been 50h and it is only 0.04% of the way through... Which if my maths is correct means it will be finished after another 2,000,000h (not real maths)

hutber@hutber:~$ badblocks -svw -b 4096 -c 200000 /dev/sda -o bb_sdc.txt
Checking for bad blocks in read-write mode
From block 0 to 1953506645
Testing with pattern 0xaa:   0.04% done, 50:47:27 elapsed. (0/783975/0 errors)

Is there a way I can run this without it taking so long?

Jamie Hutber
  • 614
  • It's not recommended to use badblocks directly. Please see my answer for the proper way to bad block with r/w testing. How big is this disk, and why is there a need to bad block it? What does the SMART Data say? – heynnema May 17 '20 at 14:14
  • Status please... – heynnema Aug 14 '20 at 18:17

2 Answers2

5

The correct way to bad block a disk is to use e2fsck, not badblocks directly. See man badblocks for more details...

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

Note: do NOT abort a bad block scan!

Note: do NOT bad block a SSD

Note: backup your important files FIRST!

Note: this will take many hours

Note: you may have a pending HDD failure

Boot to a Ubuntu Live DVD/USB in “Try Ubuntu” mode.

In terminal...

sudo fdisk -l # identify all "Linux Filesystem" partitions

sudo e2fsck -fcky /dev/sdXX # read-only test

or

sudo e2fsck -fccky /dev/sdXX # non-destructive read/write test (recommended)

The -k is important, because it saves the previous bad block table, and adds any new bad blocks to that table. Without -k, you loose all of the prior bad block information.

The -fccky parameter...

   -f    Force checking even if the file system seems clean.


-c    This option causes e2fsck to use badblocks(8) program to do
a read-only scan of the device in order to find any bad blocks.
If any bad blocks are found, they are added to the bad block
inode to prevent them from being allocated to a file or direc‐
tory.  If this option is specified twice, then the bad block scan
will be done using a non-destructive read-write test.


-k    When combined with the -c option, any existing bad blocks in the
bad blocks list are preserved, and any new bad blocks found by
running badblocks(8) will be added to the existing bad blocks
list.


-y    Assume an answer of `yes' to all questions; allows e2fsck to be
used non-interactively. This option may not be specified at the
same time as the -n or -p options.
heynnema
  • 73,937
  • 1
    I'm skeptical of this answer. I'd like to know more details about what the -cc option is doing, but it does explicitly state a non-destructive read-write test, I'd like to know if this is functionally as good as badblocks -ws would be. badblocks -w is a destructive command, which is generally fine, though something that e.g. records what was on the block, does the test, then writes original data back on, might be even more convenient since we could maybe run that on a drive and preserve its data. But it should be slower, since it'd be doing more work. – Steven Lu Aug 25 '22 at 03:24
  • @StevenLu From man badblocks it says "For this reason, it is strongly recommended that users not run badblocks directly, but rather use the -c option of the e2fsck and mke2fs programs". – heynnema Aug 25 '22 at 03:51
  • 2
    For anyone curious, the full details from man badblocks is "If the output of badblocks is going to be fed to the e2fsck or mke2fs programs, it is important that the block size is properly specified, since the block numbers which are generated are very dependent on the block size in use by the filesystem. For this reason, it is strongly recommended that users not run badblocks directly, but rather use the -c option of the e2fsck and mke2fs programs." I don't claim to be an expert here, but the context of why not use badblocks directly seems very important. – Jason Capriotti Mar 23 '24 at 14:51
  • Yeah, this answer is plain wrong if OP is only intending to do a health check on a drive and not feed the resulting bad blocks to mke2fs. And a lot of the other advice in the answer is dubious too. – marcelm Feb 12 '25 at 21:02
  • @marcelm Look at my first comment to the OP. I asked about the size of the disk, and requested SMART information. OP never responded. OP could have used SMART to run brief tests on the drive... but that won't bad block the device. OP was obviously using badblocks (incorrectly) but the point is that OP thought they had some bad blocks on the device. My answer correctly shows how to properly bad block a device... AND save any new bad blocks to the existing bad block table. – heynnema Feb 12 '25 at 21:48
  • @StevenLu The -cc option is clearly described in my informational text at the end of my answer... If this option is specified twice, then the bad block scan will be done using a non-destructive read-write test. – heynnema Feb 12 '25 at 21:58
  • "If the output of badblocks is going to be fed to the e2fsck or mke2fs programs,"

    This is archaic information. Back in the day when MFM/RLL controllers were used for drives, it was important for the OS to retain a list of bad blocks to avoid using. Starting with IDE drives (and more recently SATA) drives, the controller maintains this list transparently to the OS and remaps bad secto4rs as needed. These can be seen in SMART stats. If a badblocks is reporting bad sectors, the internal table is full and the drive is no longer usable.

     – HankB Jun 23 '25 at 13:54
4

Before changing the default variables, you should learn what they are doing.

You problem is here:

-b 4096 -c 200000

Indication that you are doing it wrong is:

(0/783975/0 errors)

You are asking the drive to write and read 781MB each time (200000 times 4096). This is beyond the capability of any SOHO drive and even most enterprise drives would not be able to handle this. These options are for optimizing for unusual drives. Some suffer bottleneck by bus and some have limits of the technology. Fitting these can allow for better precision at faster speeds - you just went the opposite way.

Here are the explanations behind the two (man badblocks):

-b block_size Specify the size of blocks in bytes. The default is 1024.

-c number of blocks is the number of blocks which are tested at a time. The default is 64.

Regarding using badblocks on SSDs, there is no reason to never do it. Just do not do it for no reason. SSDs have limited lifespan and are not block devices. This means you are not getting actual block information of the NAND, just testing the drive ability to fill with data.

Martin Ledvina
  • 41