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
