weigele@bosun1.informatik.uni-hamburg.de (Martin Weigele) (02/19/91)
weigele@bosun1.informatik.uni-hamburg.de (Martin Weigele) writes: [About SUN OEM Viper 150 streamer] >The streamer tape is successfully SCSI-recognized during boot, and it is >possible to "mt -f /dev/nrst0 <command>" as well as with /dev/rst0. >This seems to work. However, tar-ing or dd-ing from or to tapes results >in "i/o errors" (I tried with more then one tape). Here's the comment from my dealer who forwarded the information from NeXT: "Hier die Antwort von NeXT: 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 wonder if there is any "configuration trick". Unfortunately the otherwise >detailed documentation (about ODs and Exabyte drives) does give very >little documentation about /dev/rst0 type streamers. Actually, once you know you need to look up ioctl the extended release documentation has this in the manual pages. Unfortunately, I didn't have the time to try this out yet because I need to borrow the tape drive, but maybe someone else is happy with this info. One solution might be to adapt GNU tar (or maybe this has been done already. We don't have the latest version, probably). Or does anyone know about tape drives which support variable size blocks? Anyone? Martin
jlc2@cbnewse.att.com (john.chmielewski) (02/21/91)
weigele@bosun1.informatik.uni-hamburg.de (Martin Weigele) writes: >[About SUN OEM Viper 150 streamer] >>The streamer tape is successfully SCSI-recognized during boot, and it is >>possible to "mt -f /dev/nrst0 <command>" as well as with /dev/rst0. >>This seems to work. However, tar-ing or dd-ing from or to tapes results >>in "i/o errors" (I tried with more then one tape). > 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 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. ------------------- start of setmtd.c ---------------------- /* * setmtd - set SCSI tape driver to a fixed block size * by John L. Chmielewski * Tue Feb 19, 1991 */ #include <fcntl.h> #include <sys/types.h> #include <nextdev/scsireg.h> #define RSTDEVICE "/dev/rst0" #define BLOCKSIZE 512 main() { int fd, size = BLOCKSIZE; if ((fd = open(RSTDEVICE, 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
ddj@gradient.gradient.com (david johnson) (02/27/91)
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 <fcntl.h> #include <sys/types.h> #include <nextdev/scsireg.h> #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)
anderson@sapir.cog.jhu.edu (Stephen R. Anderson) (02/27/91)
Add to the tape drives for which this reported fix works the TEAC 50N (155 meg. capacity) drive I was having problems with a while ago. Martin Weigele's code to reset the st driver allows my '040 cube with OS2.0 to read and write successfully on this drive. I've explored some other paths to fix things, and will make a fuller report in a few days. The TEAC drive is available from Mac places (I got mine from Alliance Peripheral Systems, 1-800-233-7550) for around $600 including case and power supply. Steve Anderson (no connection with APS except as a satisfied customer mumble mumble...)
ddj@gradient.gradient.com (david johnson) (02/27/91)
ddj@gradient.gradient.com (david johnson) writes: > perror(RSTDEVICE); Le Oops! Correct code fragment for opening named device should be if ((fd = open(name, O_RDWR)) < 0) { perror(name); exit(1); } Sigh...