I have a brand new 8tb hd and after partitioning it, formatting it ext4 and copying data to it, I thought I'd run badblocks on it.
I get the following error. after running badblocks -s /dev/sdb

I am running on slackware 15.0 64bit.

has anyone come across this error before or come accross a work-arround.?
should it be reported upstream?

You weren't very clear about "partitioning it" .. you're basically forced to use GPT on that thing.
And no mention of brand/model, no mention of how BIOS sees the drive, whether or not it's set to ACPI or something else?
Maybe run extended smartctl test to make sure it's not a faulty drive first?
But if I had to guess based on what little info you've shared, it's probably the partition table that's messed up.

elcore: the drive has a single ext4 partition, and yes, I had to use gpt as it is over 2tb in size.
it's a wd drive. it is not being used as a boot drive (I have a separate dos partion style 2tb drive for swap and root mount)

Apparently badblocks is using 32bit vars for it's block counts. that could be fixed in source, but maybe there is a reason why not.
I am aware of 48bit lba as well as 32bit lba, and would have thought it could handle either, but maybe not.

The workaround is to specify the blocksize in the badblocks command (rather than leaving it at the default 512bytes.) The actual blocksize used can be obtained from (where /dev/sdx is your drive)
then use (in my case) this allows the number of blocks to be small enough.

I get the impression though that on even larger drives, such as 20TB the block size will either be large enough that lots of space is wasted with small files; or if bs is capped at 4k or 8k, badblocks will again hit it's 32bit limit.

2 members found this post helpful.

Seems like a limitation of badblocks, never did hit that one personally since the most block size on any drive I've had is 2048.
I've still got a few externals with 64 block size so.. when mkfs.vfat changed to 2048 default, I've had a similar issues.
Changing the default size is really up to upstream badblocks developer.

i was also concerned in case it affected the slackware installer, but the badblocks checking is always used as a -c parameter of the actual command used, eg mkswap or mke2fs etc, so I can't tell how that binary calls badblocks without delving into their source code as well. If it proves a problem no doubt it will have to be done, but as I added the large drive after installing slackware, and formatted the partition manually, I didn't test the installer on that (check for badblocks option).

I'd be rather surprised that an 8TB drive lacked SMART support. Why do people still use badblocks when smartctl is available? I know the installer still offers the badblocks option, but would it not make more sense for the installer to offer instead the option of SMART short and SMART extended/long tests if SMART support was detected?

1 members found this post helpful.

I was heartened to see you in a new thread, and in a way, I am not surprised to see you discussing hard drives, as you are known to me as the guy who applied a patch to LILO so we could use it with NVMe drives. You'll always be the hero in my book for doing that. Anyway, I hope you get your problem resolved shortly.

Happy Slacking!