mt bsf with sequential dumps to Exabyte

[Ian Boardman]

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 at park.bu.edu.
Thanks. 

Ian Boardman
ian at 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.