>> 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
