"Simon Riggs" <[EMAIL PROTECTED]> 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 might or 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 memory addresses in rapid succession. badblocks does try to address this by writing four different complementary patterns. but I'm not convinced it's really conclusive either. It's certainly not as sophisticated as memtest86 and can't really since it can't directly control the 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 OS through the regular interfaces. A low level diagnostic program can inquire about how many blocks have been remapped and how 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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
