You people crack me up. I have been trying to ignore this post for a while but can't anymore. Garbage like badblock are from the era that you still could low level format a drive. Remember those fun days? When you were all excited about your 10MB hard disk?
Use dd to read it; if it is somewhat broken the drive will reallocate it. If it is badly broken the IO will fail and it is time to toss the disk. Those are about all the flavors you have available. Running vendor diags is basically a fancier dd. On Thu, May 07, 2009 at 01:10:56AM +0200, ropers wrote: > >> On Monday 04 May 2009 17:56:43 L. V. Lammert wrote: > >> > What is the best way to do a surface analysis on a disk? > >> > > 2009/5/5 Tony Abernethy <t...@servacorp.com>: > > There is, in the e2fsprogs package, something called badblocks. > > I have used it (on Linux) to "rescue" bad disks. > > (Windows laptops -- kinda redundant?) > > > > If you care about your data, follow Steve's advice. > > > > The reality seems to be that this does exercise a disk's ability > > to relocate bad sectors so that a bad disk suddenly goes good. > > This is using a destructive surface test (badblocks -sw ...) > > Realistically, seems like the most reliable test is that disk is slower > > than it should be. > > > > Me, if I want to rely on a disk drive, I will run badblocks on it. > > The long-winded destructive test > > And I will time it, at least sporadically. > > (New disks are not immune from having problems ;-) > > The exercise maybe loses out to watching grass grow. > > I also would recommend badblocks(8), but I would recommend > badblocks -svn > instead of badblocks -sw. > > badblocks -svn also (s)hows its progress as it goes along, but does a > (v)erbose (n)on-destructive read/write test (as opposed to either the > default read-only test or the destructive read/write test). You can > check an entire device with badblocks, or a partition, or a file. The > great thing about using badblocks to check a partition is that it's > filesystem-agnostic. It will dutifully check every bit of its target > partition regardless of what's actually on it. And if you give > badblocks -svn an entire storage device to test, it will not even care > about the actual partition scheme used. Because this read/write test > can trigger the disk's own built-in bad sector relocation, this means > you can even have a disk that you can't read the partition table from, > and running badblocks -svn over it may at least temporarily fix > things. And I've used badblocks -svn e.g. to check old Macintosh > floppies. Who cares that OpenBSD doesn't know much about the > filesystem on those? badblocks does the job anyway. > > (Because of this agnosticism, it's actually questionable whether > badblocks(8) ought to be part of a filesystem-specific package, but > hey, that's what it comes in. Yea, one *could* also argue whether to > include it elsewhere by default because it's so useful, but I'm not > the one making those decisions and I guess the folks who do will do > what makes the most sense to them, so I don't feel like starting to be > a back seat driver... ;-) > > Oh, and of course it would probably be prudent to do a backup before > read/write tests, even though badblocks is well-established and (with > -n) supposed to be non-destructive. Supposed to... ;-) I've never been > disappointed but YMMV. > > regards, > --ropers
