rcw@qetzal.UUCP (Robert C. White) (02/05/88)
I had wanted to add nine track capability to my Microport box for some time, and with the help of a net person (Dave Carlsen) I located Overland Data in San Diego, California. Without being too commercial, Overland Data sells nine track tape drives for small systems. They had a tape driver for Microport 2.2, but not for 2.3. Their kernel guru, Ms. Gail Anderson, soon produced and delivered an updated driver for 2.3, and the tape unit itself, a Qualstar TC-50, which retails for $3,600 including the tape controller card. The documentation is quite professional and very straightforward. The software package for Microport includes a single mt.o file and a configuration script that will incorporate the new module into lib2. A simple make wini reconfigures the driver to support the tape drive. Unlike most drivers that I have seen, this one can be software configured to use any one of the three DMA channels, any IRQ, and any IO address. This becomes essential if you have a cartridge tape drive already installed in your system. Hardware changes involve setting a few dip switches on the controller card, and some gymnastics to fit the two connecting cables through the back of the machine. Full ioctl support is provided, including eof, weof, fsf, fsr, bsf, bsr, rewind, offline, rewoffl, status. An 'mtc' program (with source code) is supplied to execute any one of these ioctl functions. It works very well. Mag tapes can be written at either 1600 or 3200 bpi. This unit requires hand threading which I prefer over autoloading. I've fought with many an autoloading tape drive, and they never seemed to work the first try. I ran into problems using microport's strm utility. It cannot be used with the tape drive, and asks you at inappropriate times to change media and type in the new device name. Unfortunately this tape drive will not work properly at clock speeds higher than an ordinary AT. Apparently there is some new hardware in development that will solve this problem. If you try and run the tape drive at high clock speeds, the infamous double panic will occur. This tape drive will stream, provided you can read and/or write to it "quickly" enough. One way to cause streaming is to do this: (assuming tape is blocked at 512 bytes, which you wouldn't ordinarily do). cat /dev/rmt0 | tar tvf - If an good strm type utility can be developed, streaming writes could probably be accomplished. Disk throughput without buffering of some sort is simply not fast enough to maintain streaming. One objective that I had in mind was to be able to read from the cartridge tape and write directly to the mag tape without hitting the disk. This indeed works, but remember to read from the cartridge tape in 512 byte blocks. Reads of an arbitrary size from the cartridge tape drive will result in a read error. Blocks of up to 64k can be written to tape. As delivered, the maximum block size is somewhere around 10k, and the remaining memory is used to buffer the read or write. This scheme can be patched using the patch utility, but the kernel must be recreated. There is a 64k chunk of memory built into the controller card, and some modifications at boot time prevent the system from grabbing this extra memory. Using dd, you can write ebcdic tapes suitable for IBM mainframes. All of the standard unix tape utilities (cpio and tar) work as one would expect with the tape drive. Generally speaking, I feel the tape drive is a good investment if you need this capability. Using our machine in this way, we have saved tens of thousands of dollars over other solutions. Now, how about a good ethernet card? :-) Robert White boulder!qetzal!rcw