Bug 1306522

Summary: badblocks only supports 32bit int for number of device blocks
Product: [Fedora] Fedora Reporter: Yasuo Ohgaki <yohgaki>
Component: e2fsprogsAssignee: Eric Sandeen <esandeen>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 23CC: esandeen, josef, kzak, oliver
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-02-11 14:29:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Yasuo Ohgaki 2016-02-11 07:33:29 UTC 
Description of problem:

It's not a bug strictly speaking, but 32 bit int for number of blocks is not large enough for current systems.

badblocks command only supports 32 bit int for number of device blocks. This limitation could work around by specifying start/end block option. There are many large disks that exceeds 32 bit int blocks today.


Version-Release number of selected component (if applicable):



How reproducible:

Use badblocks for large disks

[root@dev ~]# LC_ALL=C badblocks /dev/md0 
badblocks: Value too large for defined data type invalid end block (11720540160): must be 32-bit value


Actual results:

badblocks: Value too large for defined data type invalid end block (11720540160): must be 32-bit value


Expected results:

badblocks works for large disks

Additional info:

After disk failure, I got large number of bad blocks on mdadm RAID5 disk even if resync reports no errors. It seems there is something wrong in mdadm RAID5 also.
Comment 1 Eric Sandeen 2016-02-11 14:29:12 UTC 
badblocks is pretty much deprecated at this point, and is almost certainly the wrong tool to be using for a situation like this.  It was designed in the floppy disk days, when loss of sectors was expected; today if you have user-visible bad blocks, your storage is bad, likely to get worse, and needs to be replaced immediately.  Tracking bad block locations won't do any good.

For example, from the upstream maintainer, on the mailing list:

"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"

The 32-bit limit is intentional:

        /* ext2 badblocks file can't handle large values */
        if (last_block >> 32) {
                com_err(program_name, EOVERFLOW,
                        _("invalid end block (%llu): must be 32-bit value"),
                        last_block);
                exit(1);
        }

which came from:

commit d87f198ca3250c9dff6a4002cd2bbbb5ab6f113a
Author: Darrick J. Wong <darrick.wong>
Date:   Wed Oct 23 19:43:32 2013 -0400

    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.

If you *really* want to try your luck, you can specify a larger block size for testing, i.e. badblocks -b 16384.  But I wouldn't really trust badblocks on large devices; it wasn't designed for this purpose.