"Simon Riggs" <simon@2ndquadrant.com> writes:
> In the past, I have used the dd command to squirt data at the disk, then
> read it back again - but there may be reasons I don't know why a success on
> that test might not be conclusive, so I personally would be happy to defer
> to someone that does.
Well that's an interesting tangent.
1) I've seen bad memory on a scsi controller once. Caused one-bit errors in data read back after being written. a dd
mightor might not find that depending on the buffer usage pattern, and depending on the pattern being written and
read.Memory errors are notoriously fickle and can sometimes be triggered only by particular bit patterns in adjacent
memoryaddresses in rapid succession.
badblocks does try to address this by writing four different complementary patterns. but I'm not convinced it's
reallyconclusive either. It's certainly not as sophisticated as memtest86 and can't really since it can't directly
controlthe placement of data in the disk's buffers.
2) The disk could be finding lots of bad blocks during the dd run and remapping them. It gives no information to the
OSthrough the regular interfaces. A low level diagnostic program can inquire about how many blocks have been remapped
andhow many spare blocks are available.
I know Maxtor is hot to have you run their PowerMax(tm) program whenever you
call tech support. I think it just runs something similar to badblocks and
asks the disk firmware if it's detected any low level problems.
In theory it can check things like the drive having trouble syncing to tracks
due to environmental factors like noise, vibrations, and heat. I don't know if
it does or not though.
--
greg
