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