Determine block size for badblocks

[Alan W. Smtih]

The excellent [How To] Hard Drive Burn-In Testing shows two ways to run `badblocks`.

The basic way:

badblocks -ws /dev/ada#

And with `-b` to tell `badblocks` to use a specific byte size that's sometimes necessary for disks over 2TB in size:

badblocks -b 4096 -ws /dev/ada#

While that last command is working fine for me, I'd like to know if there is a way to determine in advance if it's needed (and what the number should be if that should change in the future).

The badblocks wiki has a section on Block Size that mentions looking those details via:

dumpe2fs /dev/<device-PARTITION>

FreeNAS has that command. But, when I run it on a test FreeNAS system (which doesn't have any vdevs or zpools setup because I'm using to do a badblocks test), I get the following:

Code:

dumpe2fs 1.43.3 (04-Sep-2016)
dumpe2fs: Bad magic number in super-block while trying to open /dev/ada0
Couldn't find valid filesystem superblock.

Is something else needed to make `dumpe2fs` work?

Or, is there another way to determine the block size to pass to badblocks for a given disk?

 

[wblock]

dumpe2fs is for Linux e2fs (ext2) filesystems. It sounds like they are confusing filesystem blocks with hard drive blocks. They are not the same.

To discover the actual disk block size, use diskinfo:

Code:

diskinfo -v ada0
ada0
   512	 # sectorsize
   500107862016   # mediasize in bytes (466G)
   976773168	 # mediasize in sectors
   4096	 # stripesize
   0	 # stripeoffset
   969021	 # Cylinders according to firmware.
   16	 # Heads according to firmware.
   63	 # Sectors according to firmware.
   (serial number)   # Disk ident.
   Not_Zoned	 # Zone Mode

The sector size here is the size the I/O system sees. But the stripesize is the actual hardware block size used by the disk.

 

[rs225]

The purpose of badblocks is to identify bad physical sectors, so you would look at the stripesize, and if it is 4096, you use the -b to tell it that. There is no reason this only applies at 2TB, since many 1TB disks have 4K sectors (this is called 512e or Advanced Format/AF)

 

[Alan W. Smtih]

It sounds like they are confusing filesystem blocks with hard drive blocks. They are not the same.

Ah, cool. That makes sense. Thanks for `diskinfo` solution.

[Incidentally, one of my favorite things about this forum is knowing I can ask a question about something I only partially understand and get great feedback to help me learn more. Good stuff and a general "Thanks!" to everyone willing to take the time to help teach those of us who aren't experts (there was supposed to be a thumbs up emoji here, but the system ate it)]

 

[danb35]

There is no reason this only applies at 2TB

Actually, there is--because at somewhere north of 2 TB, and using the default block size of 512 bytes, badblocks can't count high enough to scan all the blocks. That's the only reason the -b 4096 flag is really used; it doesn't really have anything to do with the physical, logical, or any other block size on the target disk.

Edit: So, if you're scanning a 20 TB disk in the future, and badblocks complains (I don't have the exact error message handy, unfortunately), you could use -b 8192.

 

[rs225]

Actually, there is--because at somewhere north of 2 TB, and using the default block size of 512 bytes, badblocks can't count high enough to scan all the blocks. That's the only reason the -b 4096 flag is really used; it doesn't really have anything to do with the physical, logical, or any other block size on the target disk.

Sure enough, the source for badblocks.c doesn't show any history since 1999. If they updated it to use a 64-bit value, they wouldn't have the problem.

 

[Spearfoot]

Actually, there is--because at somewhere north of 2 TB, and using the default block size of 512 bytes, badblocks can't count high enough to scan all the blocks. That's the only reason the -b 4096 flag is really used; it doesn't really have anything to do with the physical, logical, or any other block size on the target disk.

Edit: So, if you're scanning a 20 TB disk in the future, and badblocks complains (I don't have the exact error message handy, unfortunately), you could use -b 8192.

Agreed!

The badblocks '-b' and '-c' options work together, but there are limits on how large you can set them:

• -b block-size : Specify the size of blocks in bytes. The default is 1024.
• -c number of blocks : The number of blocks which are tested at a time. The default is 64.

I suggest leaving the block size at 4096 and using the '-c' option to make badblocks test a larger number of blocks at a time. Something like 128 or 256 might be a good place to start.

 

[Alan W. Smtih]

I suggest leaving the block size at 4096 and using the '-c' option to make badblocks test a larger number of blocks at a time. Something like 128 or 256 might be a good place to start.

Out of curiosity, what does `-c` get you?

(My guess is it would speed things up a little. Am I close?)

Related assumption: Running without `-c` won't hurt anything, regardless of block size, right?

 

[danb35]

Running without `-c` won't hurt anything, regardless of block size, right?

I hope not, as I've never used the -c option.

 

[Spearfoot]

Out of curiosity, what does `-c` get you?

(My guess is it would speed things up a little. Am I close?)

It ought to speed things up a little, since badblocks would be testing bigger chunks of data at a time.

Related assumption: Running without `-c` won't hurt anything, regardless of block size, right?

Won't hurt anything at all; badblocks just uses the default value (64) if you don't specify anything.