Do the ceiling arithmetic on the drive in the opening example and the recommended fix does not clear it. The limit is 2^32 blocks, 4,294,967,296 of them [1]. An 18 TB drive at 4096 bytes per block comes to 18,000,000,000,000 / 4096 = 4,394,531,250 blocks, about 99.6 million over [17]. So -b 4096 on an 18 TB disk exits in the same second the 1 KiB default did, and the run needs -b 8192 [18]. The writeup, published on dev.to under the byline Vainamoinen, described there as the autonomous AI sysadmin running day-to-day infrastructure at the Finnish seedbox and storage host Pulsed Media [13], puts the -b 8192 threshold at 20 TB and up [6]. The drive it opens with is 18 TB [7].
The pasted error is not from that drive. It reports an invalid end block of 7812500000 [4], and 7,812,500,000 x 1024 is 8.0e12 bytes [19].
There is a second figure to reconcile. The post gives the ceiling as 2^32 blocks [1] and later says to raise the block size until the count comes back under 2^31 [8]. Those differ by a factor of two, and the error text only says the value must be 32-bit [4]. If the conservative reading is what the binary enforces, the 4 KiB ceiling is 2^31 x 4096, about 8.8 TB [20], and an 18 TB drive at 8192 comes to 2,197,265,625 blocks, still roughly 50 million over [23]. Same disk, three different block sizes depending on which constant you trust. The rule that survives all of them is the one the post closes on: if badblocks refuses to start, double the block size until the count fits [21]. And -b 4096 does have the merits claimed for it, aligned to the 4 KiB physical sectors these drives already use and faster than 1 KiB blocks [22]. Neither merit makes it a default you can stop thinking about.
badblocks is not quiet about the failure. It prints the error and is back at the prompt in under a second, with no pass 1, nothing wiped and nothing verified [4]. A destructive write-verify that finishes that fast has at least preserved your data [16]. The check the post recommends costs four seconds: sleep 4, then pgrep -c badblocks, where the count should equal the number of drives you launched and zero means they all died at setup [11].
One layer up, the same post flags a matching enumeration bug. A sd? glob matches sda through sdz and silently skips two-letter names like sdaa and sdab, so a loop over every disk in a well-stuffed JBOD covers fewer than it claims [14]. Enumerating with lsblk -dn -o NAME,SIZE,TYPE and filtering to type disk does not care how long the kernel made the name [15]. Both bugs leave the same artefact behind: a batch job that reports having done the work, with no record of how many devices it actually touched.
