Subject: Bug#554794: /sbin/badblocks: badblocks -c <huge-number> will not speed up completion time

From: Dave Witbrodt <[email-masked]>
Date: Fri, 06 Nov 2009 11:31:25 -0500

Package: e2fsprogs
Version: 1.41.3-1
Severity: wishlist
File: /sbin/badblocks

I use 'badblocks' to test new disks before I store data on them.  The
last time I used it, I was setting up a raid1 array on two 500GB disks.
The process took something like 13 hours.  (I had an unreasonable
expectation that it would take much less time!  ;)

At that time, a couple of years ago, I looked at the man page and
noticed the -c option... and made a mental note to experiment with it
next time to see if it could speed up the process.

This week, I bought two new 1.5TB drives.  Being a noob, and making
false assumptions about how 'badblocks' works (and having made no
attempt to look at the source code), I opened up 2 shell windows in
emacs and ran these commands in separate shells:

    badblocks -c 524288 -v -w /dev/sdc
    badblocks -c 524288 -v -w /dev/sdd

The intention was to let each instance of 'badblocks' write and read
512MB of data in bursts, hopefully taking advantage of economies of
scale to speed up completion time.  Since my cheap little "server"
machine here has 2GB of RAM, I thought I might as well put that RAM to
good use!

Everything started out fine.  The 'top' command showed that each
instance of 'badblocks' had acquired 512 MB of RAM, and were percolating
along barely using any CPU resources at all.  So I went to bed.

When I got up, 'top' said this:

top - 08:55:22 up  8:13,  2 users,  load average: 3.00, 2.85, 2.76
Tasks:  84 total,   1 running,  83 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.0%us,  1.7%sy,  0.0%ni, 50.6%id, 46.5%wa,  0.1%hi,  0.0%si,  0.0%st
Mem:   1927304k total,  1912440k used,    14864k free,      340k buffers
Swap:  1951888k total,   872560k used,  1079328k free,     2620k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
2563 root      20   0 1035m 1.0g   56 D   26 54.4  15:16.01 badblocks
2562 root      20   0 1035m 743m   56 D    2 39.5   8:42.62 badblocks
[...]

I was running out of RAM and hitting the swap file.

I admit disappointment, but I was only testing my idea about
'badblocks -c' to see what would happen.  Each instance had finished
with the first test pattern, so I decided that the disks were probably
good enough and I quit running 'badblocks'.

Instead of reporting an (alleged) bug in 'badblocks' -- which I doubt
that this is, since I'm probably abusing the program for purposes for
which it was not designed -- I would like to request either:

  - a README file discussion of appropriate expectations of run time for
    badblocks on modern, very large hard disks; and why abusing "-b"
    and/or "-c" is not likely to lessen the pain of waiting.

  - or, at least a blurb in the 'badblocks' man page (and "--help" text)
    in the "-w" section pointing out that abusing "-c" won't help speed
    things up.

I found a couple of archived Debian BTS reports touching on this:

  - #7173 was closed without comment 

  - #232240 has a good discussion of why "-c" cannot be expected to
    improve performance, and that IDE drives on the same channel make
    running 2 instances of 'badblocks' at once unhelpful.  (SATA
    overcomes the latter issue, of course.)

It would help the uninitiated (such as myself) if some of that #232240
discussion appeared where an interested user might expect to find it,
instead of buried in archived BTS bug reports.

Thanks,
Dave W.

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.31-0git.090921.fileserver.uvesafb (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages e2fsprogs depends on:
ii  e2fslibs                      1.41.3-1   ext2 filesystem libraries
ii  libblkid1                     1.41.3-1   block device id library
ii  libc6                         2.7-18     GNU C Library: Shared libraries
ii  libcomerr2                    1.41.3-1   common error description library
ii  libss2                        1.41.3-1   command-line interface parsing lib
ii  libuuid1                      1.41.3-1   universally unique id library

e2fsprogs recommends no packages.

Versions of packages e2fsprogs suggests:
pn  e2fsck-static                 <none>     (no description available)
pn  gpart                         <none>     (no description available)
pn  parted                        <none>     (no description available)

-- no debconf information