Bug#554794: badblocks -c and -n
Theodore Ts'o writes: > 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. 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 tagg...@debian.org
Bug#554794: badblocks -c and -n
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
Bug#554794: badblocks -c and -n
#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 tagg...@debian.org pgp0xF0cpiIyb.pgp Description: PGP signature
