On Tue, 24 Jun 2003 23:26:09 +0200, Stephan von Krawczynski said:

> sorry, you probably misunderstood my flaky explanation. What I meant was not 
a
> cached block from the _tape_ (obviously indeed a char-type device) but from t
he
> 3ware disk (i.e. the other side of the verification). Consider the tape
> completely working, but the disk data corrupt (possibly not from real reading
> but from corrupted cache).

Don't rule out odder explanations either.  True story follows.. ;)

I once had the misfortune of being the admin for a Gould PN/9080. UTX/32 1.2
came out, and since it changed the inode format on disk, it's dump/mkfs/restore
time.  So I take the last 3 full backups, and do 2 more complete dumps besides.
I checked, and *NO* I/O errors had been reported (and then I checked THAT by
giving it a known bad tape and seeing errors WERE reported).

Do the upgrade... and *every single* tape was 'not in dump/restore format'.

Finally traced it down (this was the days when oscilloscopes were still useful)
to a bad 7400 series chip on the tape controller.  The backplane was a 32-bit
bus, the tape was an 8-bit device - so there was a 4-to-1 mux that had a bad
chip.  Bit 3 would be correct for 4 bits, inverted for 4 bits, correct for
4, etc..  Tape drive *NEVER* complained, because what came over the *cable*
was correct, parity and all..

Oh, and I got the data back something like this:

cat > mangle.c
main() {
int muck[2];
  while (read(0,muck,8) == 8) {
	muck[1] ^= 0x20202020;
        write(1,muck,8);
  }
}
^D
cc -o mangle mangle.c
dd if=/dev/rmt0 bs=32k | ./mangle | restore -f -