Path: utzoo!mnetor!tmsoft!torsqnt!hybrid!scifi!bywater!uunet!gradient!ddj From: ddj@gradient.gradient.com (david johnson) Newsgroups: comp.sys.next Subject: Re: NeXT answer to tape drive problems Message-ID: <272@gradient.gradient.com> Date: 26 Feb 91 16:53:59 GMT References: <1991Feb20.202553.21798@cbnewse.att.com> Organization: Gradient Technologies Inc., Hudson MA Lines: 141 jlc2@cbnewse.att.com (john.chmielewski) writes: >weigele@bosun1.informatik.uni-hamburg.de (Martin Weigele) writes: ... >> You need to use the MTIOFIXBLK ioctl to set fixed block mode on >>the device access. Otherwise you should ensure that the transfers are >>a multiple of 512 bytes, by using the b option to tar. If you do not >>do this, the access will fail with a SCSI error. This is because the >>Viper 150 supports only fixed block size accesses. The 2.0 device >>driver assumes devices can handle variable block sizes. Hence any >>drive that supports variable size blocks will work automatically with >>the NeXT at 2.0." >I connected a Wangtec 60 MB tape drive and experienced the same problems. >Following the above advice for an alternate to the MTIOFIXBLK ioctl, I >tried tar, gnutar, and cpio with no success. I think that when you try >to read or write to the tape drive, the SCSI tape driver checks to see >if it uses the type of block size the driver is configured for, if not, >"i/o errors" is returned. I believe Martin's "Othersize you should ..." was actually meant to be read "In addition to the ioctl, you must ...." >I wrote the following short program to set the SCSI tape driver to a fixed >block size of 512 bytes. After running it, I was able to read and write to >the drive, using tar, cpio, and cat. I do not know if the driver remembers >the configuration between boots, but if it does not, the program could be >run from rc.local. I think that mt(1) should be modified to do this, and >I also think the SCSI tape driver should be "fixed" to configure itself to >the tape drive. The provided program also worked for me on an OLD Archive 60MB QIC24 full height scsi drive, and on a new Mirror Technologies QIC150 external drive I bought to use at home on both my NeXT and my wife's Mac SE/30. ($797+shipping direct from Mirror Technologies, 800-654-5294/+1 612 633 4450; I talked to Amy). The Mirror drive is based on a Tandberg 3600 transport, which supports writing in QIC150 format as well as reading QIC24 (60 meg) tapes written on other systems (I don't recall now but it may also read QIC120 mode). It is in a metal enclosure with two SCSI ports, push-button scsi selection switch, two convenience outlets, and the power switch on the back. The tape is inserted with the tape rollers on the right and the drive door is closed pushing the tape in the rest of the way. There is an LED to indicate tape is loaded and online. Standard DC6150 tapes work as advertised at 150 megabytes, and extended length tapes (DC6250) are usable for the full 250 megabytes of capacity, although the MODE_SENSE scsi command does not distinguish between the two different sized cartridges. The MODE_SENSE returns a density code of QIC150 for both, and a blocks-in-tape capacity of zero for all tapes I looked at. (The Archive drive identified a 60 megabyte tape as QIC24 density and 120000 blocks in tape). The tape speed (rated 72 ips) is not quite up to Wangtek or Archive Viper speeds (rated 90 ips), but I was able to dump my extended distribution of 179900 blocks in about 36 minutes onto an extended length cartridge, giving roughly 5Mb/min, not allowing for the overhead of dump scanning the filesystem before starting to write the tape. The tape did not stop streaming at all, except to turn around at the end of each track. I tried to work out the proper density and length parameters to provide to dump, but ended up approximating them empirically. As a conservative start, I would suggest the following options (full dump example): 150 Megabyte tape (DC6150): dump 0udsf 40000 620 /dev/rst0 /dev/rsd?a # fake density, real length or dump 0usf 9000 /dev/rst0 /dev/rsd?a # 1600 density, fake length 250 Megabyte tape (DC6250): dump 0udsf 40000 1020 /dev/rst0 /dev/rsd?a # fake density, real length or dump 0usf 15000 /dev/rst0 /dev/rsd?a # 1600 density, fake length As one experimental data point, using the 1600bpi line immediately above to write a 150 meg tape as if it were a 250 meg tape terminated with an error message indicating that it had written 9231 feet of tape (at 1600 bpi 9-track standard format). It might be possible to increase the 40000bpi psuedo- density somewhat, but 45000 was definitely too high and I think 44000 was also. Since I was working with two drives, I made some slight modifications to setmtd, and now automatically call it from /etc/rc.local as follows (from memory -- please compare to existing lines in /etc/rc for sanity): (/usr/etc/setmtd /dev/nrst0 && echo " scsi tape 0") >/dev/console (/usr/etc/setmtd /dev/nrst1 && echo " scsi tape 1") >/dev/console ------------------- start of setmtd.c ---------------------- /* * setmtd - set SCSI tape driver to a fixed block size * by John L. Chmielewski * Tue Feb 19, 1991 * * Modified to take drive name argument and default to non-rewinding mode: * by David D. Johnson (ddj@gradient.com) * Sun Feb 24, 1991 */ #include #include #include #define RSTDEVICE "/dev/nrst0" #define BLOCKSIZE 512 main(argc, argv) int argc; char *argv[]; { int fd, size = BLOCKSIZE; char *name = RSTDEVICE; if (argc > 1) name = argv[1]; if ((fd = open(name, O_RDWR)) < 0) { perror(RSTDEVICE); exit(1); } if (ioctl(fd, MTIOCFIXBLK, &size) < 0) { perror("ioctl"); exit(1); } (void) close(fd); return 0; } ------------------- end of setmtd.c ---------------------- > -jlc- > jlc@alien.att.com As a footnote, the MTIOCFIXBLK ioctl controls the format of the command the st-driver uses to read/write the tape drive. Since it does not send any information to the tape drive, it is not remembered across boots. The block size of 512 is a requirement of the formatter of each of the drives I looked at. -- Dave Johnson ddj@gradient.com (via uunet)