scott%csis.OZ@uunet.uu.net (Scott Milton) (02/09/89)
======================================= 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@csis.oz.au (Scott MILTON). CSIRO Division of Information Technology, Canberra. ACT. AUSTRA