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 -
This archive was generated by hypermail 2b29 : Mon Jun 30 2003 - 22:00:18 EST