8

I have a 4TB drive with a 4096 byte block size. I want to check a very specific set of blocks, around the 700,000,000th block or so for bad sectors.

However, badblocks seems to only support int32 as the stop and start block counts, which means that it's impossible for me to specify this range of blocks.

Is there another way I can scan this drive for badblocks? I don't want to wait the 7 hours it's going to take to test the whole drive. It is a single drive from an mdadm array so it does not contain a usable file system.

Mark Henderson
  • 280

2 Answers2

14

Tell badblocks to use the larger block size and it will work above 2TB. I used this on a WD 6TB drive:

badblocks -b 4096 -v /dev/sda
Ian D. Allen
  • 895
  • 2
    Note that this will mean the block IDs reported as bad won't be valid for mkfs. You need to use a -b that matches the blocksize of the device. – mrm Mar 06 '17 at 01:37
  • And the man page for badblocks says ("Important note") to use the -c option to e2sck and/or mke2fs to run badblocks with the correct block size; don't try to get the block size right yourself. – Ian D. Allen Feb 07 '22 at 18:58
  • 2
    This only delays the problem until you get a drive (or array) with over 17.6 TB – SurpriseDog Aug 07 '22 at 18:25
7

Patch to limit badblocks to 2^32

There appears to have been a patch made for badblocks to add this particular limitation. See here, titled: Re: [PATCH 04/25] libext2fs: reject 64bit badblocks numbers.

From: "Darrick J. Wong" <darrick.wong <at> oracle.com>
Date: Wed, 23 Oct 2013 19:43:32 -0400
Subject: [PATCH] libext2fs: reject 64bit badblocks numbers

Don't accept block numbers larger than 2^32 for the badblocks list,
and don't run badblocks on them either.

Signed-off-by: Darrick J. Wong <darrick.wong <at> oracle.com>
Signed-off-by: Theodore Ts'o <tytso <at> mit.edu>

Support won't be added to badblocks?

Looks like badblocks won't be having this feature in the foreseeable future either.

excerpt - Re: [PATCH 18/31] libext2fs: Badblocks should handle 48-bit block numbers correctly

Yeah, I think badblocks is vestigal at this point, and for huge disk arrays, almost certainly block replacement will be handed at the LVM, storage array, or HDD level. So it might be better simply to have mke2fs throw an error if there is an attempt to hand it a 64-bit block number.

                      - Ted

Some other way to do this?

I searched in vain to find some fork of badblocks or an alternative to it, but found really nothing. Your only options are to make use of a commercial tool such as SpinRite or the open source tool HDAT2. You could also use one of the many drive fitness tools (DFTs) that are provided by the HDD manufacturers. Perhaps one of these would allow for you to push past the 2^32 barrier.

What to do?

Of the options on the table I've had good success with HDAT2 and SpinRite, so I'd likely use them in that order to try and scan this region of blocks that's at the 700M range.

slm
  • 369,824
  • 1
    Just flicking through that patch (and the description) this seems to be adding a limitation of 32-bit numbers..? – Mark Henderson Aug 26 '14 at 04:22
  • 1
    @MarkHenderson - whoops, I misread that. They added it. Not sure why. I'll keep digging. – slm Aug 26 '14 at 13:06
  • A late comment, but I'm currently trying to find the source code to HDAT2, and I can't. Is this a recent change? – i336_ Aug 16 '19 at 16:25
  • @i336_ - unclear, I'd follow up w/ the mailing list for hdat2. – slm Aug 17 '19 at 16:11