7

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
  • 270
  • 2
  • 11
  • Please indicate the OS, distribution, version number AND if the OS is a 32- or 64- bit OS. The limitation you have might be due to the "bitedness" of the OS you are using. – mdpc Aug 26 '14 at 06:16
  • @mdpc Ubuntu 14.04, 64-bit. – Mark Henderson Aug 26 '14 at 06:17
  • Is the badblocks application a 32- or 64- bit application? Yes there are some cases where common 32-bit applications live and work on a 64-bit system. – mdpc Aug 26 '14 at 06:18
  • @mdpc I have no idea to be honest. I'm not enough of a *nix person to even know how to check. – Mark Henderson Aug 26 '14 at 21:38
  • file /usr/sbin/badblocks or file /sbin/badblocks and that should tell you the bittiness of the application. – mdpc Aug 26 '14 at 23:20
  • @mdpc - it states that it's `ELF 64-Bit` – Mark Henderson Aug 27 '14 at 01:38
  • Corresponding bug in Debian: [#764636 Badblocks does not support large disks](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764636). –  Mar 20 '18 at 02:10

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
  • 885
  • 6
  • 11
  • 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
  • 1
    This only delays the problem until you get a drive (or array) with over 17.6 TB – SurpriseDog Aug 07 '22 at 18:25
6

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
  • 363,520
  • 117
  • 767
  • 871
  • 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