[817] in linux-scsi channel archive
Re: Scsi tape problems.
daemon@ATHENA.MIT.EDU (David Monro)
Sat Oct 19 10:55:11 1996
Date: Sun, 20 Oct 1996 00:51:51 +1000 (EST)
From: David Monro <davidm@fuzzbox.psrg.cs.usyd.edu.au>
Reply-To: David Monro <davidm@fuzzbox.psrg.cs.usyd.edu.au>
To: "Stephen C. Tweedie" <sct@dcs.ed.ac.uk>
cc: wperkins@us.net, ncr53c810@colorado.edu, linux-scsi@vger.rutgers.edu,
babydr <babydr@nwrain.net>
In-Reply-To: <199610191013.LAA00422@dax.dcs.ed.ac.uk>
<large amounts of stuff about cpio storing checksums on the tape deleted>
Actually, what I was suggesting was _not_ storing checksums on the tape, but
adding a feature to 'restore' to calculate them while reading the tape, and
check them against the checksums of the files on disk. I agree that once data
is on the tape the drive will figure out if it gets corrupted.
Doing this is simply doing a full compare, but if you generate checksums
with 'dump' and store them in a file then you can compare the checksum of what
you thought was dumped to the tape with what is on there now, and avoid the
problem of verifying against a live filesystem. This should protect you
against bus corruption of data going to the tape. It doesn't protect you from
bus corruption on data coming from the drive, but I figure if that is happening
you will probably know about it (you get swap space corruption, all your
programs either segfault or fail to start with strange messages, or my
favorite method to test for bus corruption is
dd if=/dev/hda1 bs=1024k count=<insert large number here> | sum
repeated a few times.
Personally I don't verify my dumps at all, because I have never seen any
corruption on the bus (and I have tried the above test on all my devices). All
my restores have worked fine.
Enjoy,
David
