Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: ian@central.bu.edu (Ian Boardman)
Newsgroups: comp.sys.sun
Subject: mt bsf with sequential dumps to Exabyte
Keywords: Miscellaneous
Message-ID: <966@brchh104.bnr.ca>
Date: 30 Dec 90 01:04:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 49
Approved: Sun-Spots@rice.edu
X-Original-Date: 27 Dec 90 22:52:23 GMT
X-Sun-Spots-Digest: Volume 9, Issue 415, message 5
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

We have a SparcStation running SunOS 4.1.0 with an Exabyte in an ESM.
When I start with a new tape, I can do a sequence of dump tape files, one
after the other, as in:

	# foreach part ( a d g h )
	> dump 0unf - /dev/rxd0$part | dd bs=62k of=/dev/nrst0
	> end

I can read these tapes one after the next, or I can use mt fsf <n> to seek
into the tape <n> files.  What I can NOT do is start writing at the end of
the last tape file after I've done a rewind, NOR can I back space to an
intermediate file.  Every time I do "mt bsf", it rewinds the tape.  Also,
on any hard error, such as trying to write at the end of the last tape
file, I get a hard error and the tape rewinds even though I used
/dev/nrst0, the NO REWIND device.

Sun has been polite, but frankly useless.  They did not try out my
exersize using a sequence of dump files, but a series of EMPTY tar files.
This struck me as irrelevant.  I would be very willing to bet there is
something wrong with the way I do the dump sequence, i.e.  using dd as
shown above.  We have also used this form with the same problematic
results:

	# dump 0unsbdf 346 126 466033 <host>:/dev/nrst0 /dev/rxd0<part>

The tape is by no means filled by a full dump of the disk, so we intended
to have multiple tape files per tape.  On a Sun 4/110, we use Delta
Microsystem's driver for their Exabyte, and the mt operations bsf, fsf,
and weof work perfectly.  I use the pipe command with their version of dd,
which fills out every block to be the specified block size (i.e. 62k).  

Other than my dump command, the next most likely candidate for the source
of the problem is Sun's driver.  It seems like the drive reads and writes
correctly.  The problem seems to be the way it handles the end of file
marks.

Please reply with any advise or helpful comments to ian@park.bu.edu.
Thanks. 

Ian Boardman
ian@park.bu.edu

Excuse me for this errata.  The command pipe I showed is used to get the data
over to the *remote host* supporting the Exabyte (the SparcStation), thus I 
should have said:

	> dump 0unf - /dev/rxd0$part | rsh <host> dd bs=62k of=/dev/nrst0

dump is run on a Solbourne Sparc running an emulation of SunOS 4.0.3.