On Mon, Jul 10, 2017 at 03:19:28PM -0700, Matt Taggart wrote:
> 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?
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....
