Subject: Bug#554794: badblocks -c and -n

From: Matt Taggart <[email-masked]>
Date: Mon, 10 Jul 2017 15:19:28 -0700

#554794 concerns the time it takes to run badblocks for any particular
value of the -c option (count of blocks to do at once).

At the time (2009) it wasn't clear if larger values of -c improved runtime,
although one user (in 2011) reports 10% improvement.

The current -c (block count) default is 64 blocks.
The current -b (block size) default is 1024 bytes.

AFAICT the last time they were increased was 2004 (#232240, -c from 16 to
64).

A related bug (#764636) when running badblocks on a 14tb device was solved
by switching to -b 4096.

Given the device size increases and RAM/CPU improvements since all these
things occurred, is there any value to increasing the defaults? Does anyone
have any data? If not then what tests would be valuable?

I often run many badblocks instances at once on separate SATA devices (so
no bus contention), what are the optimal settings for that case?

Thanks,

--
Matt Taggart
[email-masked]

---

From: Theodore Ts'o <[email-masked]>
Date: Tue, 11 Jul 2017 10:23:40 -0400

> no bus contention), what are the optimal settings for that case?

I have to ask --- ***why*** are you (and other people) running
badblocks in 2017?  Badblocks as a thing started becoming irrelevant
for e2fsprogs's purpose sometime around 2003-2005, when SATA was
introduced, and drive electronics were smart enough that they could be
largely counted upon to do automatic bad block redirection in the
drive.

Also, drives have gotten large enough that no matter what kind of
optimizations we could make to badblocks, the cost benefit ratio of
using badblocks went negative a long, long, ***LONG*** time ago.

As a result, I personally don't do much maintenance to badblocks,
since as I have free time, there are far more important things to
worry about than trying to optimize (or even provide I18N support, or
other crazy things people have asked for) in this program.  As always,
however, patches will always be gratefully accepted for review....

	 	      	     		   - Ted

P.S.  Yes, I have considered removing badblocks from e2fsprogs
altogether.  The main reason why I haven't is that it's a small (28k),
mostly harmless, and inoffensive binary.  Given the average increase in
bloat of, say, most of the other binaries in Debian, it hasn't even
been worth the effort to deprecate it....

---

From: Matt Taggart <[email-masked]>
Date: Tue, 11 Jul 2017 10:35:09 -0700

> largely counted upon to do automatic bad block redirection in the

Personally I use it for a few things:

1) as a way of forcing the drive to test every block and force to to
internally reallocate any sectors that are marginal _before_ the drive
is in production. The SMART tests are supposed to do this, but they
are opaque and up to the vendor to implement correctly. If I use
badblocks -w I know each (O/S visible) block gets tested 5 times.

2) as a way of exercising/burning-in the mechanism to avoid deploying a
drive that is likely to fail. I time the badblock run and if the time
diverges significantly from other drives of the same model, I know
something is wrong. As a side benefit it exercises other components in
the path, io controller, ram, cpu. The SMART tests should also work
for this, but again it's hard to measure.
(side note, I remember ~2000 someone (VA Linux Systems? joeyh?
cerberus?) having a tool that did burn-in on their servers by running
cpuburn in parallel with a bunch of copies of badblocks running on the
(then SCSI) drives.)

3) as a cheap and easy way to wipe data from drives. Using -w with it's
5 different patterns is a good way of ensuring the data is
unrecoverable before reusing/recycling the drive.

If you know of better options for these tasks I'm happy to switch to
something other than badblocks.

Thanks,

-- 
Matt Taggart
[email-masked]