>> On Monday 04 May 2009 17:56:43 L. V. Lammert wrote:
quoted text
>> > What is the best way to do a surface analysis on a disk?
>>

2009/5/5 Tony Abernethy <tony@servacorp.com>:
quoted text
> 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