Date: Tue, 18 Apr 1995 16:09:17 -0700 (PDT) From: Douglas Ambrisko <ambrisko@tcs.com> To: bugs@ns1.win.net (Mark Hittinger) Cc: current@FreeBSD.org Subject: Re: DAT tape problems Message-ID: <199504182309.QAA04563@cozumel.tcs.com> In-Reply-To: <199504181609.MAA15803@ns1.win.net> from "Mark Hittinger" at Apr 18, 95 12:09:48 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Hittinger writes:
|
| > From: Doug Rabson <dfr@render.com>
| >
| > I just attempted to read back a dump from a DAT tape to test our backup
| > strategy and disturbingly, the file which read back from the tape was
| > corrupted. The directory was intact but when the dump was extracted,
| > there was a checksum error on one file and when comparing the extracted
| > tree with the original, at least one file had been corrupted.
| > My DAT drive probes as a 'WangDAT Model 3400DX' and it is set to use
| > compression. Does anyone have an idea what is happening?
|
| I am using one here with success and have not seen this problem. I have
| been using it since the first snap (not on 2.0R).
|
| I am running 3/22 snap now, not -current.
|
| I have noticed a problem with the last file on the tape. Could this be
| what you are seeing? I have placed a dummy file as the last file to be
| backed up to get around this issue.
This dummy file fix is usually and indicator that you are using the
tape device wrong. Most tape drivers (if not all?) are fixed block.
Therefore when you write to the tape, the archive must be a multiple of
this fixed block. "tar" does this almost right, if you use compression
(ie tar -z) then it just pipes the output from tar -> gzip -> tape device.
To fix this do something like
tar cfvz - <directories etc> | dd obs=10240 of=<tape device> conv=sync
I beleive tar should be fixed such that it forks itself so that
you get tar->gzip->tar tape handler and then we could do multi-volume
backups with tar!
But this isn't an issue with me, since I usually do the dd trick to
backup to a remote tape device which uses a couple of dd tricks anyways.
Also, QIC tapes are usually 512 and I've notice some DAT tapes >512 so
maybe some program have 512 hard-wired? Note 10240 is a multiple of
1024 & 512 which cover most blocking methods. Also reading and writing on
block boundries makes the tape drive/driver happier.
So try the dd thing and then you can isolate the problem a little more
and maybe you can use this as a work-around.
BTW this stuff happens on a 1542, NCR chip and most other computer systems
I've used.
Doug A.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504182309.QAA04563>