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.
