Subject: EXABYTE HOWTO FOR SGIs
From: [email-masked] (Harry Mangalam)
Date: 6 Jan 1994 06:55:25 GMT
Newsgroups: comp.sys.sgi.hardware

Here it is; a primitive "HOWTO" about getting EXABYTE tape drives to
work on SGI's.  To be accurate, this is how I got an ANDATACO-supplied
EXB-8505 to give me backup rates of about 0.5 MB/s from an Indigo^2 running
4.0.5H - your mileage will vary.  (This is not a plug for any particular
EXABYTE supplier - they all buy from EXABYTE, repackage them, and ship them
out the door, with varying amounts of value added.  ANDATACO simply had the
best price for the drive I needed at the time and their tech support turned
out to be quite acceptable).

   Thanks to Harry Shamansky (The ElectroScience Laboratory, Ohio State),
John Valdes (Dept of Geophysical Sciences, U. Chicago), Sam Fulcomer (Brown
U), Chuck McCalister (EXABYTE) and of course the weightless one (Dave
Olson) for advice, corrections and pointers, although errors that have
crept thru or remain uncorrected are mine.  Warning:  This advice is free
and therefore worth exactly that much.  

                         Heed at your own risk!  

                        Verify! Verify! Verify!

EXPLICIT WARNING:  There is a VERY IMPORTANT GOTCHA here.  If you modify
the files as described below, make backups using the modified drivers, and
then you have a system disk crash, the UNMODIFIED kernel that you load from
a CD will almost certainly NOT be able to read your tapes to restore your
system and data. To wit, the following exchange:

From John Valdes: 
   "If I use the exabyte for system backups, using the standard 8200 mode
(nsv, or compressed mode, 8200c), what are the implications of the above
when trying to restore a crashed system disk? With a crashed system disk,
I'd have to boot from cd, and in particular, I'd have to boot a kernel w/o
my tpsc mods, one which presumedly thinks the exabyte is a QIC drive. From
my previous experience, I would have to conclude that I would be unable to
read my backup tape. Is this correct? If this is true, then would it be
possible to write a tape with the exabyte in a manner so that it would be
readable by the tpsc driver as if it the exabyte were a QIC drive? What
device file should I use (non-variable, no-swap?) and what blocksize (for
mt setblksz)?"

Dave Olson replies:
   "You are correct. So if you want a full tape to be restorable in the
miniroot, *with the miniroot kernel*, and the drive type is unknown, you
want to write the backup with 512 byte blocks, in fixed block mode. Or, at
least backup your kernel in the first tape file, and use 512 byte blocks
(fixed or variable) to do that first tape file."

So make sure that you have at least the minimal system and files required
to finish the restore on a tape that has been written with the above
parameters!

OK, on with the show:

   SGI's come with minimal support for Exabytes:  There is some support for
the 8200 and 8500, but unless you like tracking code, it's not well
documented.  Without doing the gymnastics described below, it may work -
the OS may detect it correctly if it's an 8200 or 8500, and even if not,
you may get it to work with the generic SCSI tape driver (which thinks it's
a QIC tape), but your transfer rates will probably be abysmal; mine were ~
70-140 KB/s).

The important files are:

/usr/sysgen/master.d/tpsc - contains data for the device drivers including
the SCSI tape drivers that are of interest here. 
   (In IRIX 5.1, it's /var/sysgen/master.d/tpsc and in 5.2 it's
   /var/sysgen/master.d/scsi, for reasons best explained by Dave Olson.)

/dev/MAKEDEV - a script that when executed, makes the device drivers
(actually the 'device special files') according to info detected by the OS
and info found in the device files in "/usr/sysgen/master.d" .

/dev/rmt/tps...., /dev/mt/tps.... - the device driver files that are
created by MAKEDEV to provide access to the tape drive (there is no
difference between the two sets of files - in IRIX 5.1, /dev/mt is a link
to /dev/rmt).
   For the Exabytes, they will typically be grouped like this:

tps1d4nrnsv.8200    
tps1d4nrnsv.8200c  
tps1d4nrnsv.8500    
tps1d4nrnsv.8500c   
   ^ ^^ ^ ^ ^   ^
   | || | | |   | - compression enabled or not
   | || | | | - drive emulation
   | || | | - variable blocking enabled
   | || | - no (byte) swapping
   | || - no rewind on close
   | | - SCSI ID #  (detected by OS)             
   | - SCSI controller number (detected by OS)       

   To take advantage of the different features of the drive, you have to
access it via the appropriate driver ie. if you want to take advantage of
variable blocking that can significantly increase the efficiency of
transfer, you have to specify a driver that supports it (tps1d4nsv.8500c,
for example).  If you consistently use one driver, you should make a
symbolic link to it from /dev/tape ie. 

# mv /dev/tape /dev/tape.orig 
# ln -s /dev/rmt/tps1d4nsv.8500c /dev/tape    

so that any access you make to the tape will be via the appropriate driver.

   The MAKEDEV script creates a link to *an* appropriate driver, but it may
not be the one you want to use, hence the above contortion.  It is a good
idea to use a 'rewind-on-close' driver as a default so that you don't leave
the tape in a non-rewound state to mess up the next user (ie. don't use a
driver containing the 'nr' setting).

To modify the above-mentioned files "/usr/sysgen/master.d/tpsc" and
"/dev/MAKEDEV":
  
1) Make backups of them!
2) Modify "/usr/sysgen/master.d/tpsc" so that it corresponds to your
configuration - the appropriate section of my "/usr/sysgen/master.d/tpsc"
is shown below.  

                                                        .
                                                        .
                                                        .

        /* There are now 3 densities, 8500c/8505 mode, 8500 mode and 8200.
         * If someone make bogus dev numbers using all 4 density bits,
         * it will default back to 8500c mode.  The inventory string sets
         * the drive up exactly like the 8500. */

        { EXABYTE8200, TP8MM, 7, 8, "EXABYTE", "EXB-8200", 1, "\16", 
                {0, 0, 0, 0},
         
MTCAN_BSF|MTCAN_BSR|MTCAN_PREV|MTCAN_CHKRDY|MTCAN_VAR|MTCAN_SETSZ|
            MTCAN_SILI|MTCAN_CHTYPEANY,
          80, 4*60, 25*60, 5*60, 1024, 128*1024},

        { EXABYTE8500, TP8MM, 7, 8, "EXABYTE", "EXB-8500", 6,
"\40\4\16\0\200\7",
                {0x0, 0x14, 0x0, 0x0},
         
MTCAN_BSF|MTCAN_BSR|MTCAN_PREV|MTCAN_CHKRDY|MTCAN_VAR|MTCAN_SETSZ|
            MTCAN_SILI|MTCAN_CHTYPEANY|MTCAN_SETDEN|MTCAN_SPEOD|MTCAN_SYNC|
                MTCAN_SEEK,
          80, 4*60, 25*60, 5*60, 1024, 128*1024},

        { EXABYTE8500, TP8MM, 7, 8, "EXABYTE", "EXB-8505", 6,
"\40\4\16\0\200\7",
                {0x8c, 0x15, 0x90, 0x14},
         
MTCAN_BSF|MTCAN_BSR|MTCAN_PREV|MTCAN_CHKRDY|MTCAN_VAR|MTCAN_SETSZ|
            MTCAN_SILI|MTCAN_CHTYPEANY|MTCAN_SETDEN|MTCAN_SPEOD|MTCAN_SYNC|
                MTCAN_SEEK,
          80, 4*60, 25*60, 5*60, 1024, 128*1024},

The sequence that makes up the 2nd line of each stanza ("{0x8c, 0x15, 0x90,
0x14}," for the EXB-8505) is significant for the default settings.  See
below.
   Also, Harry Shamansky uses another trick to extract use and compression
stats from his drive; see Footnote [1] at end.

               +++++++++++++++++++++++++++++++++++++++++++++++++++  

For the /dev/MAKEDEV modifications, it is similar - here is my
interpretation, starting with the pre-existing EXB-8500 stanza:

                        *Device:*EXB-8500*) \
                            set        v nrv nsv nrnsv ; \
                            for add in 4  5   6    7 ; do \
                                mdev=`expr $$minor + $$add`; \
                                mknod $${prf}$$1 c $$maj $$mdev; \
                                shift; \
                            done; \
                            for dens in 0 8 ; do \
                                case $$dens { \
                                0) kden=8500;; \
                                8) kden=8200;; \
                                }; \
                                set        "" nr ns nrns v nrv nsv nrnsv ;\
                                for add in 0  1  2    3  4  5   6    7 ; do
\
                                    mdev=`expr $$minor + $$add + $$dens`;\
                                    mknod $${prf}$$1.$$kden c $$maj
$$mdev;\
                                    shift;\
                                done; \
                            done ;; \
                        *Device:*EXB-8505*) \
                            set        v nrv nsv nrnsv ; \
                            for add in 4  5   6    7 ; do \
                                mdev=`expr $$minor + $$add`; \
                                mknod $${prf}$$1 c $$maj $$mdev; \
                                shift; \
                            done; \
                            for dens in 0 8 16 24; do \
                                case $$dens { \
                                0) kden=8500c;; \
                                8) kden=8500;; \
                                16) kden=8200c;; \
                                24) kden=8200;; \
                                }; \
                                set        "" nr ns nrns v nrv nsv nrnsv ;\
                                for add in 0  1  2    3  4  5   6    7 ; do
\
                                    mdev=`expr $$minor + $$add + $$dens`;\
                                    mknod $${prf}$$1.$$kden c $$maj
$$mdev;\
                                    shift;\
                                done; \
                            done ;; \

Note that I've re-arranged the "kden=" statements to put the drive in
'8500c' mode by default - the order has to correspond to the "{0x8c, 0x15,
0x90, 0x14}," order in the EXB-8505 stanza in the
"/usr/sysgen/master.d/tpsc" file.

After you've done this, reboot, allow the autoconfig at restart, and then
run the MAKEDEV script (# MAKEDEV tps) to make the tape drivers.  You
should end up with an 'ls' of the /dev/mt and /dev/rmt that looks something
like:

mt% ls tps1d4*
tps1d4              tps1d4nrns          tps1d4nrv           tps1d4nsv
tps1d4.8200         tps1d4nrns.8200     tps1d4nrv.8200      tps1d4nsv.8200
tps1d4.8200c        tps1d4nrns.8200c    tps1d4nrv.8200c     tps1d4nsv.8200c
tps1d4.8500         tps1d4nrns.8500     tps1d4nrv.8500      tps1d4nsv.8500
tps1d4.8500c        tps1d4nrns.8500c    tps1d4nrv.8500c     tps1d4nsv.8500c
tps1d4nr            tps1d4nrnsv         tps1d4ns            tps1d4v
tps1d4nr.8200       tps1d4nrnsv.8200    tps1d4ns.8200       tps1d4v.8200
tps1d4nr.8200c      tps1d4nrnsv.8200c   tps1d4ns.8200c      tps1d4v.8200c
tps1d4nr.8500       tps1d4nrnsv.8500    tps1d4ns.8500       tps1d4v.8500
tps1d4nr.8500c      tps1d4nrnsv.8500c   tps1d4ns.8500c      tps1d4v.8500c

Now you can try out the drivers with bru, tar (I use the FSF/gnu tar),
dump, etc and verify (!) that the drivers are working correctly (or at
least working considerably better).

A few remaining points that still troubled me:  
   After doing the preceding, I was able to increase the transfer rate from
an initial ~70 KB/s to ~500 KB/s, which was good, but not considering that
the drive is supposed to be capable of 1MB/s (Sam Fulcomer has reported
700KB/s from a Challenge/IRIX 5.1 combination).  
   On my tape drive, I can set both 8200/8500 mode and compression/no
compression by a pushbutton.  There is no appreciable difference in
transfer rate between the comp/no comp setting, although the LED that
signals compression indicated that it is ocurring.
   With compression on, I typically get over 0.5 MB/s tranfer when backing
up binary files and only about 300 kB/s when backing up text files.  I
expected the reverse to be true.  What gives?

   The answer has to do with the fact that the rate at which data goes on
the tape depends on how fast the SCSI channel can be filled (although 1
MB/s should be no problem for even a SCSI-1 controller), how efficient the
compression is, and most importantly, how much overhead there is for the
amount of data going on the tape.  Large files have less overhead than
small ones and although it seems counter- intuitive, I get faster transfer
of binaries than of text.

Footnotes:

[1] Harry Shamansky used a neat but possibly dangerous (for novices)
approach to extract stats from his drive after a backup; the stats are
normally cleared because of the way that SGI has decided that the drive
should left.  Harry S's approach (NOT supported by SGI):

   Here's the stuff I use. One note, however. There are two conflicting
   considerations. If you desire compression statistics, then you should
set
   the drive up as TPUNKNOWN, since SGI feels that the omission of a
trailing
   EOD on the no-rewind device is a bug. [We don't, and we like stat's, so
we
   set it this way] If you do, then hinv will respond with "unknown" as the
   type, as will mt -status, but this has no effect on the drive overall. 
   (If you want more specifics about this isue, let me know, we have the
   complete details.) Otherwise, use TP8MM in place of TPUNKNOWN, but the
   compression statistics will be lost.

<<Warning from Dave Olson:  The above is true *only* if you have made other
mods so that TPUNKNOWN is basicly the same as an exabyte.  {The reason that
SGI does not support this approach is} the exabyte drive will leave the
tape in a trashed state (no eod mark, which causes all kinds of drive
(*NOT* driver) problems when reading up to that point later on, if the
system is shut down without the tape being rewound/unloaded, etc., OR a
SCSI bus reset occurs before the rewind).>>

   Here's our mod to /usr/sysgen/master.d/tpsc - add the comments to the
Exabyte
   stanza; append the driver description to that already existing (I've
   included the apprpriate bit of my "/usr/sysgen/master.d/tpsc"
afterwards):

        /* There are now 3 densities, 8505 mode, 8500 mode and 8200.  
         * If someone make bogus dev numbers using all 4 density bits, 
         * it will default back to 8505 mode.  The inventory string sets 
         * the drive up exactly like the 8500. */

        /* Note that the TPUNKNOWN is needed to workaround the move that
           SGI makes when they handle a TP8MM after write (i.e. a bsFM, 
           then fsFM) which clears the compression statistics) */

        { TPUNKNOWN, TPUNKNOWN, 7, 8, "EXABYTE", "EXB-8505", 6, 
                "\40\4\16\0\200\7", 
                {0x8c, 0x15, 0x14, 0x8c},
         
MTCAN_BSF|MTCAN_BSR|MTCAN_PREV|MTCAN_CHKRDY|MTCAN_VAR|MTCAN_SETSZ|
            MTCAN_SILI|MTCAN_CHTYPEANY|MTCAN_SETDEN|MTCAN_SPEOD|MTCAN_SYNC|
                MTCAN_SEEK,
          80, 4*60, 25*60, 5*60, 1024, 128*1024},

   If you have an 8500c drive instead/as well, then you can simple
   replace/copy the above and replace "EXB-8500" with "EXB8500C".

NB:  Know what you're doing before you try this!!

And his mods to "/dev/MAKEDEV"

   In /dev/MAKEDEV, it's rather simple. We prefer to have the compression
on
   by default, hence our 0) setting points to the 0x8c desnity seen above
in
   tpsc: 

                        *Device:*EXB-8505*) \
                            set        v nrv nsv nrnsv ; \
                            for add in 4  5   6    7 ; do \
                                mdev=`expr $$minor + $$add`; \
                                mknod $${prf}$$1 c $$maj $$mdev; \
                                shift; \
                            done; \
                            for dens in 0 8 16; do \
                                case $$dens { \
                                0) kden=8505;; \
                                8) kden=8500;; \
                                16) kden=8200;; \
                                }; \
                                set        "" nr ns nrns v nrv nsv nrnsv ;\
                                for add in 0  1  2    3  4  5   6    7 ; do
\
                                    mdev=`expr $$minor + $$add + $$dens`;\
                                    mknod $${prf}$$1.$$kden c $$maj
$$mdev;\
                                    shift;\
                                done; \
                            done ;; \

   (obviously the same comments hold for the 8500c above)

HS also has a couple of programs that assist in extracting the stats - you
should contact him for the details: [email-masked].

Let me know if anyone has problems with this approach, or can point out a
better one.

Cheers and Happy New Year!
Harry

Harry Mangalam, VCO/Micro+Mol Genetics, Irvine Hall, Coll of Med, UC
Irvine,
Irvine, CA, 92717, Vox:(714) 856-4824, Fax:(714) 725-2118, [email-masked]

                          --- Life is messy ---

Newsgroups: comp.sys.sgi.admin,comp.sys.sgi.hardware
From: [email-masked] (Terry Fong)
Subject: Exabyte 8205 WORKING!
Summary: using an 8205 to read/write 8200 format tapes
Keywords: Exabyte, 8205
Organization: NASA ARC/ Information Science Division
Date: Fri, 7 Jan 1994 20:22:32 GMT

Hi all,

Just wanted to publicly thank Dave Olson for his help in getting my
Exabyte 8205 drive working properly. If you missed my previous posts,
I recently installed an 8205 on a 4D/30 and have since been trying to
get it to read & write tapes which can be used on a Sun attached 8200.
The solution is as follows:

1) Modify /usr/sysgen/tpsc/master.d to add support for the Exabyte
8205 (my drive came from Andataco) by adding the following:

    /* The following is entry adds support for an Exabyte 8205. The
     * 8205 is not supported by SGI under IRIX 4.0.5
     *
     */
    { EXABYTE8500, TP8MM, 7, 8, "EXABYTE", "EXB-8205", 6, 
	"\40\4\16\0\200\7", {0x14, 0x90, 0x90, 0x90},
      MTCAN_BSF|MTCAN_BSR|MTCAN_PREV|MTCAN_CHKRDY|MTCAN_VAR|MTCAN_SETSZ|
	MTCAN_SILI|MTCAN_CHTYPEANY|MTCAN_SETDEN|MTCAN_SPEOD|MTCAN_SYNC|
	  MTCAN_SEEK,
      80, 4*60, 25*60, 5*60, 1024, 63*1024},
				    ^
				    |--- see below

Note: Harry Mangalam's "EXABYTE HOWTO FOR SGIs", which was posted
recently suggests using "128" instead of "63". This is okay if you are
only going to read tapes on an SGI. If, however, you want to be able
to read your tapes on a Sun, you have to use "63". In Dave Olson's words:

| Change the 128 to 63, and Sun systems will be a lot happier (assuming
| you are using the variable block devices.  Sun, for reasons best known
| to them, won't do > 64K DMA, and translated that into the largest
| block size they write; they do some godawful things with sizes >
| 64KB-2 bytes.  This isn't necessary if the 8200 is on another
| SGI system, but it sounds like for you, they are all on Suns.

Also, this entry specifies the four densities {0x14, 0x90, 0x90, 0x90}
which correspond to {8200 mode, 8200 compressed mode, 8200 compressed
mode, 8200 compressed mode}. 

2) Modify /dev/MAKEDEV and add the following to create devices:

    *Device:*EXB-8205*) \
	set        v nrv nsv nrnsv ; \
	for add in 4  5   6    7 ; do \
	    mdev=`expr $$minor + $$add`; \
	    mknod $${prf}$$1 c $$maj $$mdev; \
	    shift; \
	done; \
	for dens in 0 8; do \
	    case $$dens { \
	    0) kden=8200;; \
	    8) kden=8200c;; \
	    }; \
	    set        "" nr ns nrns v nrv nsv nrnsv ;\
	    for add in 0  1  2    3  4  5   6    7 ; do \
		mdev=`expr $$minor + $$add + $$dens`;\
		mknod $${prf}$$1.$$kden c $$maj $$mdev;\
		shift;\
	    done; \
	done ;; \

This will create the appropriate devices (i.e., tps0d3nsv.8200,
tps0d3.8200c, etc.).

3) autoconfig, run /dev/MAKEDEV, and reboot.

Once this is done, you can create tapes on the 8205 (in 8200 mode)
which can be read by a Sun's 8200. Just use the non (byte) swapping,
variable blocking device (e.g., "/dev/mt/tps0d3nsv.8200") when making
tapes. This is required since Sun's always use non (byte) swapping,
variable blocking devices.

------------------------------------------------------------------------------
To make a dump tape of "/", for example, use the following on the SGI:

  dump 0bdfsu 56 54000 /dev/mt/tps0d3nrnsv 6000 /

Note that blocking is specified to be "56" since Sun's mtio(4) can
only r/w a maximum of 65535 bytes and 56 KB is the highest multiple of
8 KB less than 65535 (see SGI's dump(1M) for details).

This tape can then be read on a Sun's 8200 using restore:

  restore if /dev/nrst1

------------------------------------------------------------------------------
To make a tar tape, on the SGI:

  tar cvf /dev/mt/tps0d3nsv blah...

This tape can then be read on a Sun's 8200 using:

  tar bxvf 126 /dev/rst1
------------------------------------------------------------------------------

Thanks again Dave!

Cheers,

Terry Fong
NASA Ames Research Center
-- 
_______________________________________________________________________________
 "You do not understand anything       Terry Fong <[email-masked]>
  until you understand it in more      NASA Ames, M/S 269-3, Moffett Field, CA
  than one way..." -- Marvin Minsky         (415) 604-6063, (415) 604-6081 lab

From: [email-masked] (Dave Olson)
Newsgroups: comp.sys.sgi.hardware
Subject: Re: EXABYTE HOWTO FOR SGIs
Date: 8 Jan 1994 08:24:17 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <[email-masked]> [email-masked] (Steve Dempsey) writes:
| Harry Mangalam writes:
| >   SGI's come with minimal support for Exabytes:  There is some support for
| >the 8200 and 8500, but unless you like tracking code, it's not well
| >documented.  Without doing the gymnastics described below, it may work -
| >the OS may detect it correctly if it's an 8200 or 8500, and even if not,
| >you may get it to work with the generic SCSI tape driver (which thinks it's
| >a QIC tape), but your transfer rates will probably be abysmal; mine were ~
| >70-140 KB/s).
|
| Now you've got me worried.  I've been using 8200 and 8500 Exabytes on
| a 4D/25 at 4.0.x for three years, and on a Challenge at 5.0.1 since last March.
| I've never had a bit of trouble with them.  I never had to modify the kernels,
| and I've always been able to achieve the advertised transfer rates (240KB/sec
| for the 8200, 500KB/sec for the 8500).  I've even been able to read the tapes
| from a miniroot.
| 
| Have I just been lucky, or do these changes apply only to enabling the
| data compression features?

I thought that this part was going to get reworded...

It's accurate in some sense, but misleading.  SGI supports, and is
fully functional, for the 8200 and 8500, and the performance for the
drives we ship is close to what the drive can achieve.  3rd party
drives may vary.  8205 and 8505 and 8[25]0[05]C drives aren't officially
supported, but can mostly be made to work pretty well.

SGI no longer sells Exabytes on the "low end" systems, and officially
they aren't supported (except for those we sold for those in the past,
i.e., we "officially" don't support them on new systems/purchases),
but since the driver is identical, they do in fact work, and I believe
all the support folks don't worry about the technicality.

--

The most beautiful things in the world are              |   Dave Olson
those from which all excess weight has been             |   Silicon Graphics
removed.  -Henry Ford                                   |   [email-masked]