badblocks fails instantly on 8 TB+ drives: the 32-bit block limit and the -b 4096 fix

A writeup on dev.to documents a quiet failure mode in badblocks, the long-standing Linux disk-testing utility: pointed at a modern large drive, it can exit before touching a single block, leaving the disk untested and, if you backgrounded the job, entirely unnoticed.

The post's author, described as an automated sysadmin running day-to-day infrastructure at Pulsed Media, a Finnish seedbox and storage host, hit the problem while burning in refurbished 18 TB drives. A destructive write-verify pass launched as badblocks -wsv /dev/sdb returned to the prompt in under a second with the message 'Value too large for defined data type invalid end block (7812500000): must be 32-bit value'. No progress bar, no first pass, nothing written or verified.

The 32-bit block-count ceiling

According to the dev.to post, badblocks addresses disks in blocks, keeps block numbers in a 32-bit integer, and defaults to a 1 KiB block size. The block count therefore has to stay under 2^32, about 4.29 billion, which caps the addressable device at roughly 4.4 TB. An 8 TB drive counted in 1 KiB units comes to around 7.8 billion blocks, well past the limit, and the tool rejects the run during setup. That is why the failure is instant rather than a partial pass: the counter overflows before the first block is ever read.

Passing -b 4096

The fix is a single flag: raise the block size until the count fits. badblocks -b 4096 -wsv /dev/sdX counts that same 8 TB disk as roughly 1.95 billion blocks, safely under the ceiling. Because the size limit scales with block size, 4 KiB blocks cover devices up to about 17.6 TB, which the post says is essentially everything shipping today. Past roughly 20 TB, step up to -b 8192 and beyond; the suggested rule of thumb is to keep doubling the block size until badblocks accepts the count.

The author also argues that 4 KiB should simply be your default on any large drive. It matches the physical sector size modern disks already use, and the post notes it is faster than 1 KiB accesses anyway, so there is no downside.

How backgrounding hides the failure

The costlier part of the story, per the post, is operational rather than numeric. A write-verify pass on an 18 TB drive takes days, so the natural instinct is nohup badblocks -wsv /dev/sdb > /root/sdb.log 2>&1 & and walk away. But if the block-count overflow fires, badblocks prints its error and exits within the first second, and nohup routes that error into a logfile nobody is watching. You come back expecting a half-finished burn-in and find the drive was never touched; as far as shell history is concerned, the job ran.

The post recommends two habits instead. Run the burn-in under screen or tmux rather than nohup, and confirm the process actually survived setup — across a batch of drives, sleep 4; pgrep -c badblocks should return a count equal to the number of drives launched, and zero means they all died at startup. And treat a burn-in that finished in one second as a failed run, not a completed one.

The sd? glob misses disks too

A related enumeration foot-gun appears in the same writeup: the shell glob sd? matches only single-letter device names, sda through sdz. On a dense box with many drives and HBAs, the kernel starts assigning two-letter names such as sdaa and sdab, which the glob silently skips — so a loop meant to cover every disk quietly ignores some of them. The suggested replacement is to enumerate from lsblk -dn -o NAME,SIZE,TYPE | awk '$3=="disk"{print $1}', which does not care how long a device name has grown and lets you filter by reported size rather than guessing letters.

Why it matters

badblocks with -w is a destructive, write-everything test used precisely because it screens disks before they carry real data — the post's context is a host verifying refurbished drives before customers depend on them, and it warns that -wsv wipes whatever it is pointed at. A run that dies at launch produces no signal at all: no console error where you can see it, no partial results, just a silent no-op. That is the difference between catching a marginal drive and putting it into service. The broader lesson applies to any long-running infrastructure job: verify the process is alive in the seconds after launch, because an instant exit is a failure wearing the costume of a finish.