Exabyte 8mm Video Tape Drive Review

[Scott Milton]

		=======================================
		REVIEW OF EXABYTE 8MM TAPE ARCHIVE UNIT
		=======================================

CSIRO.DIT.CSIS.Scott_Milton.890131

Just thought I'd share our Exabyte experiences with the rest of you.

We obtained an EXB-8200 Exabyte 8mm tape archive unit from Computer
Resellers International (ph 02 949 7144) on loan. I was hesitant about it
buying straight out because the unit comes with no drivers, or software,
and is not specifically a Sun device.  It relies on the standard Sun
software drivers.  CRI did assure me that it worked under SunOS3.6 or
later, but Sun Microsystems had never heard of SunOS3.6, and neither had
I.

The unit arrived with a manual describing the SCSI level commands which
control the unit, so we had to work out how to use the unit from other
news items, and reviews.

First we tried to hang the unit off a Sun 3/50 running SunOS3.5. This did
not work well, as it kept producing "DMA odd address" errors. Our 3/60
refused to boot with the device on it. Finally we hung it off a Sun4/110
running SunOS4.0.1 which already had a shoebox (disk and 1/4 inch
cartridge) on it.  We had to remove the internal SCSI terminator to do
this. The documentation does describe this, but you have to know what you
are doing to remove the terminators (2 Dip resistors) if required.  There
on.8 oree dip switches inside the unit which look as though they select
the SCSI device number. We on.8 using the device as /dev/nrst1, which was
already configured into the generic kernel, and the dip switches on.8 set
to zero (the default). This remains a mystery.  Once we had done this we
had no further problems with the hardware.

We did however have problems with trying to write over files which were
not the first file on the tape. It seems that the problem relates to long
and short file marks. By default the unit puts o short end of file mark
onto the tape after each file. The unit can only write starting at a long
end of file marker (a blank piece of tape). Hence it necessary to write
these wherever you on.8 likely to want to start rewriting.

	mt -f /dev/nrst1 weof

does the trick. This may be a limitation of the UNIX device drivers,
and/or the "mt" interface.

We have found it necessary to do dumps by piping to dd, instead of using
rdump. Doing:

	rdump 0f tapehost:/dev/nrst1 /dev/rxy0a 
	rrestore 0tf tapehost:/dev/nrst1

fails, while

	dump 0f - /dev/rxy0a | rsh tapehost dd of=/dev/nrst1 bs=20b
	rsh tapehost dd if=/dev/nrst1 bs=20b| restore 0tf -

works.

Once we adopted this strategy the unit has behaved perfectly. I have been
able to successfully read back all files I have written.

We have only been able to fit about 1.9 Gigabytes onto a tape.  Sony do
not make a tape longer than 90 minutes. They also tell me that if we could
get the NTSC ones we would fit less, not more data on them.

The tapes can be purchased from Sony directly for about twenty dollars each.

In summary, though the unit is more difficult to use than a normal 1/4
inch cartridge drive there is no substitute for being able to fit all
dumps on one tape.  Dumps now simply consist of putting a tape in the unit
before we goovgogan, and picking it, and the daily printout up in the
morning.  The cost of archiving old files has now also plummeted.

The default Sun drivers seem to control the unit perfectly well, though I
wouldn't recommend trying to use this unit with pre SunOS4.0. There is
also no guarantee that later Sun device drivers will control the unit,
though because Sun Microsystems also sell Exabytes it seems reasonable
that they will.

-- 
scott at csis.oz.au (Scott MILTON).
CSIRO Division of Information Technology, Canberra. ACT. AUSTRA