Re: Write cache

"Simon Riggs" <simon(at)2ndquadrant(dot)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 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