NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/sys/next/hardware/1583

Text File | 1992-09-02 | 8.4 KB | 203 lines

Newsgroups: comp.sys.next.hardware
Path: sparky!uunet!netnews!capd.jhuapl.edu!waltrip
From: [e-mail]
Subject: Re: Sun "Archive Python" Tape Drive (long)
Message-ID: <[e-mail]>
Lines: 191
Sender: [e-mail]
Organization: CAPVAX, JHU/APL
References: <[e-mail]>
Date: Wed, 2 Sep 1992 19:03:10 GMT

In article <[e-mail]>, [e-mail]
(John B. Lockhart) writes:
> My boss had a few dozen Sun 150 meg tape drives lying about gathering dust,
> so I thought I'd snarf one and use it to backup my 'station with.  Wrong.
>
> I connected it on it's lonesome (as SCSI id 4) to the NeXT, with a terminator,
> and get I/O errors on all read/writes with gnutar.
>
> The NeXT recognizes the device by name, /dev/rst0 does cause the drive to
> whirr/rewind the tape on close, mt will write an eof to the tape, and I'm
> sure I've got the blocking factor right (126).  I've also tried it without
> the terminator, and with a different terminator.
>
> Any ideas on how to get rid o' the I/O errors?
>
    I've responded to some previous posters by email when this has come up
    before but am posting a response here because I believe that, with
    some judicious editing, the answer--which was previously worked out
    by Dave Johnson--might go into the FAQ.  (In fact, I thought it was
    in there but couldn't find it in my copy--maybe I don't have the
    latest version.)

    Here 'tis.
Quote-------------------------------------------------------------------------

X-NEWS: capvax comp.sys.next: 39269Path: aplcomm!uunet!gradient!ddj
From: [e-mail] (david johnson)
Newsgroups: comp.sys.next
Subject: Re: NeXT answer to tape drive problems
Message-ID: <[e-mail]>
Date: 26 Feb 91 16:53:59 GMT
References: <[e-mail]>
Organization: Gradient Technologies Inc., Hudson MA
Lines: 141

[e-mail] (john.chmielewski) writes:

>[e-mail] (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/[phone]; 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 ([e-mail])
 *    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(name); /* changed according to jlc's
                 post of 26 Feb 91         */
        exit(1);
    }
    if (ioctl(fd, MTIOCFIXBLK, &size) < 0)
    {
        perror("ioctl");
        exit(1);
    }
    (void) close(fd);
    return 0;
}
------------------- end of setmtd.c ----------------------

>                 -jlc-
>        [e-mail]

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
    [e-mail] (via uunet)

Unquote----------------------------------------------------------------------

I believe I have seen other testimony that this works.  I believe
some other solutions may have been posted.  This, or some other
similar program, may have been posted to the archives.  If it
doesn't work, I'd like to know (don't have my tape drive yet so I
haven't personally checked).

_/_/_/_/ _/_/_/_ _/      _/      _/ _/     _/   _/_/_/_/_/ _/_/_/_/ _/ _/_/_/_/
_/  cfwaltrip     _/    _/_/    _/ _/_/    _/       _/     _/    _/ _/ _/    _/
_/       _/_/_/    _/  _/  _/  _/ _/_/_/   _/       _/     _/_/_/_/ _/ _/_/_/_/
_/  Internet: <[e-mail]>  _/       _/     _/  _/   _/ _/
_/_/_/_/ _/          _/      _/ _/      _/ _/_/_/_/ _/     _/    _/ _/ _/