
HALVARD'S COOKBOOK FOR USING DLTS UNDER ON SUNOS 4.1.x and 5.x.
---------------------------------------------------------------------------

by Halvard Halvorsen, systems consultant at Skrivervik Data as/Norway.

version 1.3. - dated 1996-february-05.

comments ? - please email me at Halvard.Halvorsen@trd.sdata.no.

DLT stands for Digitial Linear Tape; a technology originally developed and
marketed by Digital but later sold to Quantum who now sell and further
develop the DLT's. They come mainly in two variants - the 2x00 and 4x00
series - either as single devices with 20 GB (2000) and 40 GB (4000)
(compressed) capacities or as stackers (2500,2700 and so on).

As this is written there is no official support from Sun on these drives;
but Sun are soon the resell the 4000 and 4700 under the SparcStorage name.
Future versions of Solaris 2.x might however include support.

This document explains how to set up and use the DLT 2000 and 4000 
half inch tape drives on both SunOS 4.1.x (Solaris 1.x) and 
SunOS 5.x (Solaris 2.x).

This cookbook does not include instructions for use and setup with 
special purpose backup programs like Networker.



INDEX.

 1. CONFIGURING SUNOS FOR USE WITH DLT'S.
 	1.1 SunOS 4.1.4 (and probably all other 4.1.x's).
	1.2 SunOS 5.3.
	1.3 SunOS 5.4 and 5.5.

 2. CONNECTING AND VERYFYING THE DLT.

 3. DEVICES TO USE.
	3.1 SunOS 4.1.4/DLT 2000.
	3.2 SunOS 4.1.4/DLT 4000.
	3.3 SunOS 5.x/DLT 2000.
	3.4 SunOS 5.x/DLT 4000.

 4. PARAMETERS FOR DUMP/UFSDUMP.
	4.1 SunOS 4.1.4/DLT 2000.
	4.2 SunOS 4.1.4/DLT 4000.
	4.3 SunOS 5.x/DLT 2000.
	4.4 SunOS 5.x/DLT 4000.
 	4.5 BPI,blocking factor,speeds and MTBF.

 5. DENSITY INDICATORS. (or: density select-don't use it if you dont mean it!).

 6. DETAILED INFORMATION ON MY CONFIGURATION FILES.
	6.1 Density codes for the DLT 2000.
	6.2 Density codes for the DLT 4000.
	6.3 Configuration file for 4.1.4.
	6.4 Configuration file for 5.3.
		6.4.1 Problem with zero block size under SunOS 5.3.
		6.4.2 Halvard's setup for 5.3/2000.
		6.4.3 DEC's setup for 5.3/2000.
		6.4.4 Halvard's vs DEC's 2000 setup - or why you should 
		      avoid DEC's setup.
	6.5 Configuration file for 5.4/5.5.
		6.5.1 Problem with non-zero block size under SunOS 5.4/5.5.
	6.6 To REEL or not to REEL.
	

 7. THOSE DRIVE OPTIONS - WHAT DO THEY MEAN?
 
 8. OTHER DLT'S - STACKERS (2500,2700,4500,4700) AND XT'S
 	(2000xt,2500xt,2700xt).

 9. CompacTape III,CompacTape IIIxt and CompacTape IV.

10. NOTE ON MICROCODE/FIRMWARE UPDATES.

11. WRITING YOUR OWN ENTRIES FOR THIRD PARTY TAPE DRIVES.

12. CORRECT USE OF THE "probe-scsi" COMMAND.

13. PLANNED EXTENSIONS OF THIS DOCUMENT.

14. DLT COOKBOOK AVAILABILITY ON THE NET.

 APPENDIX A - SOURCES.
 APPENDIX B - THANKS.
 APPENDIX C - LEGAL NOTICE.


	
 1. CONFIGURING SUNOS FOR USE WITH DLT'S.

For all files you are likely to edit or otherwise change I recommend for 
you to take a backup before applying your changes (including /vmunix when
making a new kernel under 4.1.x).
I use vi for editing all configuration files to avoid problems
with expanding tab's and so on.

Hint: use "cp -p configfile configfile.orig" to preserve the date on
the original file.

Also it is generally a good idea to apply the latest scsi and kernel
related patches before starting out with your DLT confiuration
to ensure a stable environment. Check vs the latest 
Solaris patch reports from Sun for the various versions of SunOS to
find information on this topic.



 1.1 SunOS 4.1.4 (and probably all other 4.1.x's).

Edit the file /usr/sys/scsi/targets/st_conf.c - the last lines should look
something like this after including information about the DLT.

note - 5 spaces between DEC and DLT2000 and one space between
Quantum and DLT2000/DLT4000.

Your vendor may have changed the string that the drive
presents itself as (many companies OEM these drives) - do a 
probe-scsi/probe-scsi-all from the
boot-monitor and carefully note the output to get the correct string 
and then edit the file according to the probe-scsi output.

/* Exabyte 8505 */
{
        "Exabyte EXB-8505 8mm Helical Scan", 16, "EXABYTE EXB-8505",
        ST_TYPE_EXB8500, 1024,
        (ST_VARIABLE | ST_BSF | ST_BSR | ST_LONG_ERASE),
        5000, 5000,
        { 0x14, 0x15, 0x8C, 0x8C },
        {  0, 0, 0, 0 }
},
/* DEC 1/2" Cartridge - DLT 2000 */
{
	"DEC     DLT2000", 15, "DEC     DLT2000", ST_TYPE_REEL, 16384,
	(ST_REEL | ST_VARIABLE | ST_BSF | ST_BSR),
	400, 400,
	{ 0x17, 0x18, 0x80, 0x81 },
	{ 0, 0, 0, 0 }
},
/* Quantum 1/2" Cartridge DLT 4000 */
{
        "Quantum DLT4000", 15, "Quantum DLT4000", ST_TYPE_REEL, 16384,
        (ST_REEL | ST_VARIABLE | ST_BSF | ST_BSR),
        400, 400,
        { 0x80, 0x81, 0x82, 0x83  },
        { 0, 0, 0, 0 }
}

};
int st_ndrivetypes = (sizeof (st_drivetypes)/sizeof (st_drivetypes[0]));

#endif	/* NST > 0 */




Verify that st_drivetype in /usr/sys/scsi/targets/stdef.h looks 
similar to this (it normally does):

struct st_drivetype {
	char	*name;			/* Name, for debug */
	char	length;			/* Length of vendor id */
	char	vid[24];		/* Vendor id and model (product) id */
	char	type;			/* Drive type for driver */
	short	bsize;			/* Block size */
	int	options;		/* Drive options */
	int	max_rretries;		/* Max read retries */
	int	max_wretries;		/* Max write retries */
	u_char	densities[NDENSITIES];	/* density codes, low->hi */
	u_char	speeds[NSPEEDS];	/* speed codes, low->hi */
};


After editing the file st_conf.c make a new kernel (config/make as usual;
consult your system documentation or the file /sys/`arch -k`/conf/README
if you do not know how to make a new kernel) and copy it to /vmunix.
I have only tested this under 4.1.4 - but it should also work under 
earlier 4.1.x's.



 1.2 SunOS 5.3.

insert these lines before the first "name=" in /kernel/drv/st.conf :

tape-config-list = 
"DEC     TZ87", "DEC TZ87 DLT", "dlt2000-data",
"DEC     DLT2000", "Digital DLT2000 DLT", "dlt2000-data",
"DEC     DLT2500", "Digital DLT2500 DLT", "dlt2000-data",
"DEC     DLT2700", "Digital DLT2700 DLT", "dlt2000-data",
"Quantum DLT4000", "Quantum DLT4000 DLT", "dlt4000-data",
"Quantum DLT4500", "Quantum DLT4500 DLT", "dlt4000-data",
"Quantum DLT4700", "Quantum DLT4700 DLT", "dlt4000-data";

dlt2000-data = 1, 0x33, 16384, 0x21d, 4, 0x17, 0x18, 0x80, 0x81, 2;
dlt4000-data = 1, 0x33, 16384, 0x21d, 4, 0x80, 0x81, 0x82, 0x83, 2;

 1.3 SunOS 5.4 and 5.5.

insert these lines before the first "name=" in /kernel/drv/st.conf :

tape-config-list = 
"DEC     TZ87", "DEC TZ87 DLT", "dlt2000-data",
"DEC     DLT2000", "Digital DLT2000 DLT", "dlt2000-data",
"DEC     DLT2500", "Digital DLT2500 DLT", "dlt2000-data",
"DEC     DLT2700", "Digital DLT2700 DLT", "dlt2000-data",
"Quantum DLT4000", "Quantum DLT4000 DLT", "dlt4000-data",
"Quantum DLT4500", "Quantum DLT4500 DLT", "dlt4000-data",
"Quantum DLT4700", "Quantum DLT4700 DLT", "dlt4000-data";

dlt2000-data = 1, 0x33,  0, 0x21d, 4, 0x17, 0x18, 0x80, 0x81, 2;
dlt4000-data = 1, 0x33,  0, 0x21d, 4, 0x80, 0x81, 0x82, 0x83, 2;

Note: there is a bogus uncommented DLT entry in the Solaris 2.5
configuration file - leave it uncommented ;-|
See chapter 6 for detailed notes on the configuration files.



 2. CONNECTING AND VERYFYING THE DLT.

Shut down your Sun workstation/server and power off the machine
and all scsi-devices.
Connect the DLT to the scsi-bus using good cables and make sure the
bus is terminated correctly. Set the scsi-id; id 4 or 5 are the most common
to use - i have used 5 for my testing. 

If possible use a separate or underutilized SCSI bus for the DLT.
Running the tape drive (especially a DLT2000) on the same bus as
the disk drives will never let you achieve any good throughput according
to Rohbeck of Quantum/Germany.
You bought the DLT because of performance didn't you ?

Power on the devices/machine again and halt the boot process 
with STOP-A (L1-A) (or the BREAK key if you have an ASCII console).
Use the "probe-scsi" command from the boot-monitor (or "probe-scsi-all") 
to verify that the drive is connected properly.

Note: output from probe-scsi will not always be correct if you enter the
PROM monitor by breaking the boot process!
According to Sun this will be the case especially on the
new Ultra machines. See chapter 12 for more on this.

Boot the machine - for SunOS 5.x use "boot -rv", for SunOS 4.1.4 use "boot".
When booting you should see a message similar to these:

"st4:	<Digital DLT2000 DLT>" 
"st5:	<Quantum DLT4000 DLT>"				for SunOS 5.x and
"st1: <Vendor 'DEC     ' Product 'DLT2000         '>" 
"st1: <Quantum DLT4000>"				for 4.1.4.

On SunOS 5.x an "mt -f /dev/rmt/0 status" should give a first line
looking like this for the 2000/4000.

"REEL tape drive:" 

If the drive does not identify itself as shown for 5.x you have probably 
missed a space or something in your st.conf file (4.1.x will give you
"SCSI tape drive:").



 3. DEVICES TO USE.

 3.1 SunOS 4.1.4/DLT 2000.

- assuming you have set the scsi-id to 5.

use /dev/rst1  for 2.6 GB uncompressed mode.
use /dev/rst9  for 6   GB uncompressed mode.
use /dev/rst17 for 10  GB uncompressed mode.
use /dev/rst25 for 20  GB compressed mode.

Use /dev/nrst1,/dev/nrst9,/dev/nrst17 and /dev/nrst25 for the
non-rewinding devices.

 3.2 SunOS 4.1.4/DLT 4000.

use /dev/rst1  for the 10 GB uncompressed mode using a CompacTape III.
use /dev/rst9  for the 20 GB compressed mode using a CompacTape III.
use /dev/rst17 for the 20 GB uncompressed mode using a CompacTape IV.
use /dev/rst25 for the 40 GB compressed mode using a CompacTape IV.

 3.3 SunOS 5.x/DLT 2000.

- assuming that the DLT is the first tape device on the scsi-bus (lowest id).

use /dev/rmt/0l for 2.6 GB uncompressed mode.
use /dev/rmt/0m for 6   GB uncompressed mode.
use /dev/rmt/0h for 10  GB uncompressed mode.
use /dev/rmt/0c for 20  GB compressed mode.

Use /dev/rmt/0ln,/dev/rmt/0mn,/dev/rmt/0hn and /dev/rmt/0cn
for the non-rewinding devices.

 3.4 SunOS 5.x/DLT 4000.

use /dev/rmt/0l for the 10 GB uncompressed mode using a CompacTape III.
use /dev/rmt/0m for the 20 GB compressed mode using a CompacTape III.
use /dev/rmt/0h for the 20 GB uncompressed mode using a CompacTape IV.
use /dev/rmt/0c for the 40 GB compressed mode using a CompacTape IV.



 4. PARAMETERS FOR DUMP/UFSDUMP.

 4.1 SunOS 4.1.4/DLT 2000.

dump 0bdsf 126 62500 32000 /dev/rst17 /dump_partition 
	for dumping in 10 GB uncompressed mode.
dump 0bdsf 126 62500 64000 /dev/rst25 /dump_partition
	for dumping in 20 GB compressed mode.

 4.2  SunOS 4.1.4/DLT 4000.

dump 0bdsf 126 62500 32000 /dev/rst1 /dump_partition 
	for dumping in 10 GB uncompressed mode using a CompacTape III.
dump 0bdsf 126 62500 64000 /dev/rst9 /dump_partition 
	for dumping in 20 GB compressed mode using a CompacTape III.

dump 0bdsf 126 82000 55000 /dev/rst17 /dump_partition
	for dumping in 20 GB uncompressed mode using a CompacTape IV.
dump 0bdsf 126 82000 110000 /dev/rst25 /dump_partition
	for dumping in 40 GB compressed mode using a CompacTape IV.
	
My size recommendation for 4.1.4 are based on information ("nn% done") from
dump using a 1 GB filesystem.

 4.3 SunOS 5.x/DLT 2000.

/usr/sbin/ufsdump 0bdf 126 62500 /dev/rmt/0h /dump_slice
	for dumping in 10 GB uncompressed mode.
/usr/sbin/ufsdump 0bdf 126 62500 /dev/rmt/0c /dump_slice
	for dumping in 20 GB compressed mode.

I was able to back up around 9.5 GB using the uncompressed device and
over 21 GB using compressed mode using the above commands on file
systems containing a mix of text and binary files; compression rates 
will depend on the data you are trying to compress.

  4.4 SunOS 5.x/DLT 4000.

/usr/sbin/ufsdump 0bdf 126 62500 /dev/rmt/0l /dump_slice
	for dumping in 10 GB uncompressed mode using a CompacTape III.
/usr/sbin/ufsdump 0bdf 126 62500 /dev/rmt/0m /dump_slice
	for dumping in 20 GB compressed mode using a CompacTape III.
/usr/sbin/ufsdump 0bdf 126 82000 /dev/rmt/0h /dump_slice
	for dumping in 20 GB uncompressed mode using a CompacTape IV.	
/usr/sbin/ufsdump 0bdf 126 82000 /dev/rmt/0c /dump_slice
	for dumping in 40 GB compressed mode using a CompacTape IV.




  4.5 BPI,blocking factor,speeds and MTBF.

Read the man pages for dump/ufsdump - the above is just to show examples
on a level 0 dump with my parameters and my devices.

62500 BPI is the standard density for the 2000 according to DEC and Quantum.
82000 BPI is the standard density for the 4000 according to DEC and Quantum.
(My DEC manual lists 81600 BPI and the Quantum papers lists both
82000 BPI and 81633, I use 82000 as it is a round number ;-) ).

126 is the maximum blocking factor for dump/ufsdump.

Speeds observed when writing with dump/ufsdump :

Sparcstation Classic	: > 500 Kbyte/s (DLT 2000, same chain as disk)
Sparcstation 20		: > 700 Kbyte/s	(DLT 2000, same chain as disk)
Sparcserver 1000	: > 1.0 MB/s	(DLT 2000, same chain as disk)
Ultra 1			: > 1.4 MB/s	(DLT 2000, same chain as disk)
Sparcserver 1000	: ~ 2.0 MB/s	(DLT 2000, separate controllers)

According to DEC and Quantum the 2000 drive is capable of speeds up to
1.25 MB/s in uncompressed mode and 2.5 MB/s write in compressed mode.
The 4000 should be capable of 1.5 MB/s in uncompressed mode and
in compressed mode 3.0 MB/s on write and 3.5 MB/s on read.

Comments/new entries on the table above most welcome.

MTBF is 80 000 hours and estimated head life is 10 000 hours
for both drives.

According to DEC's 4000 manual the media can endure 500 000 passes and
it has a shelf life of 10 years.

	

 5. DENSITY INDICATORS (or: density select-don't use it if you dont mean it!).

The 2000 drive has 5 indicators on the left and 4 on the right hand side.
The 4000 drive has 6 indicators on the left and 4 on the right hand side.
The ones on the left are used to indicate the density. There is also a
density select button placed below the density indicators. The density
select button always override whatever you select in software (ie which
device you write to). My recommendation is that you leave the select button
alone. The drive automatically read pre-recorded tapes in whatever format
you wrote it in. Also you do avoid pushing the buttons and there is no need to
watch/decode the density override lamp and blinking density lamps.
I find using the drive easier when selecting the density i want from SunOS.

On another note - the density indicator lamps on my tested 2000 was
somewhat slow to respond. The 4000's I've seen did not have this problem.

If you go from 6 GB mode to 10 GB mode on the 2000 
it generally takes some time before the 6 GB lamp lit off and
for the 10 GB lamp to lit. The same applies to the compress lamp.
This can be a little confusing if you only put a few megabytes
on the tape  - so be patient ;^)

Also when doing dump/ufsdump on large filesystems it takes a while
for the command to build it's mapping and thus the lamps will not
change before a new tape header is actually written.

You can not put different densities on the same DLT tape - the drive 
use the density which was selected at BOT. 

Rohbeck writes:

" The density indicator lamps light up according to the new format
  as soon as the tape has been initialized to the new format. This
  includes rewriting the tape header which takes a few seconds.
  You cannot change the density in the middle of a tape, but you can turn
  compression on and off on the fly."



 6. DETAILED INFORMATION ON MY CONFIGURATION FILES.

You can skip this chapter if you want to - it is only here to justify
my selections and to tie some loose ends. As you are likely to find lots
of other entries on the DLT on the net and from your vendor I have included
this rather long and detailed chapter to explain why my recommended
configuration files look the way they do. There are several ways of
configuring this device and not one is "the correct one" - however the
information provided below will enable you to understand why my recommendation
looks the way it does and hopefully if you read the rest of this document
it will enable you to change the DLT's behaviour to your taste if you so
want.



 6.1 Density codes for the DLT 2000.

First the density codes - I use these for the 2000

0x17 is the density code for  2.6 GB uncompressed mode at 42 500 BPI.
0x18 is the density code for  6.0 GB uncompressed mode at 42 500 BPI.
0x80 is the density code for 10.0 GB uncompressed mode at 62 500 BPI.
0x81 is the density code for 20.0 GB   compressed mode at 62 500 BPI.

These are the ones I prefer to use; both Digital,Quantum and Tallgrass
will also list 0x19 as one of the density codes to use for the 2000.

0x19 gives the same result as the 0x81 code - but I prefer to not use it;
it is likely to give some confusion when reading the configuration file
(two codes for the same density). Also on page 7-48 in the
DEC manual for the 2000 0x19 is listed as "10 GB" - see the table below.
This just adds to the confusion so I prefer to just throw away the 0x19 code
and I recommend for you to do the same thing.

The DEC manual for the 2000 lists the following codes:

  00h - use default density (or Native default = 20 GB compressed)
  0Ah - 6667 bpi MFM serial cart. tape X3B5/86-199 (read only)
  16h - 10000 bpi MFM serial cart. tape X3.193-1990 (read only)
  17h - 42500 bpi MFM serial cart. tape X3B5/91-174 - 2.6 GB
  18h - (Same as 17h but with 56 track pairs vs 24) - 6.0 GB
  19h - 62500 bpi, 64 track pairs, serial cart tape - 10 GB (see note above!).

The (now outdated) DEC manual does not list the 0x80 and 0x81 codes for
the 2000- I've got them from Tallgrass/Quantum and they work. Rohbeck again:

"  The 0x80 etc are vendor unique density codes. We had
   to introduce them because SunOS is unable to enable/disable compression
   using the standard way, so we created the additional codes which change
   the format and enable/disable compression at the same time.".

Quantum has newer manuals and also Application Notes that lists the correct
density codes. The Application Notes are available on the web - but the
current ones point in different directions. For example the entries recommended
for 5.3 is totally different to 5.4 with regards to the order of the density
codes,they use the BSD compability devices in Solaris 2.x instead of Solaris
ones and they also fail to mention the block size error for 5.3.
However the recent updated Application Notes are much better than the
previous versions ;-)

Rohbeck of Quantum will receive detailed information on these matters.



 6.2 Density codes for the DLT 4000.

The DEC manual for the 4000 lists all of the 2000 density codes plus these
in the chapter on mode select:

  1Ah - 81633 bpi, 64 track pairs, serial cart tape - 20 GB
  7Fh - No change from previous density.
  80h - 62500 bpi, 64 track pairs, serial cart tape - 10 GB (no compression)
  81h - 62500 bpi, 64 track pairs, serial cart tape - 20 GB (with compression)
  82h - 81633 bpi, 64 track pairs, serial cart tape - 20 GB (no compression)
  83h - 81633 bpi, 64 track pairs, serial cart tape - 40 GB (with compression).


   
 6.3 Configuration file for 4.1.4.

Part of st_conf.c (just showing the 2000) :

/* DEC 1/2" Cartridge */
{
        "DEC     DLT2000", 15, "DEC     DLT2000", ST_TYPE_REEL, 16384,
        (ST_REEL | ST_VARIABLE | ST_BSF | ST_BSR),
        400, 400,
        { 0x17, 0x18, 0x80, 0x81},
        { 0, 0, 0, 0 }
}

The explanation of these fields is found in /usr/kvm/sys/scsi/targets/stdef.h :

struct st_drivetype {
	char	*name;			/* Name, for debug */
	char	length;			/* Length of vendor id */
	char	vid[24];		/* Vendor id and model (product) id */
	char	type;			/* Drive type for driver */
	short	bsize;			/* Block size */
	int	options;		/* Drive options */
	int	max_rretries;		/* Max read retries */
	int	max_wretries;		/* Max write retries */
	u_char	densities[NDENSITIES];	/* density codes, low->hi */
	u_char	speeds[NSPEEDS];	/* speed codes, low->hi */
};

The density codes _should_ go from low to high and if you consult chapter
3.1&6.1 they do. My st_conf.c differ from DEC's (and others you are likely
to find) with regard to the 0x19 code. 

You are likely to be provided with configuration files from other sources
that do not list the density codes in the "low->hi" order.
I (now) prefer to do it according to the SunOS 4.1.x man page;
even if it means that you have to use devices such as /dev/nrst25.

And once again- be aware of the 5 spaces in the "DEC     DLT2000" string.



 6.4 Configuration file for 5.3.

Small part of st.conf (example with just the 2000 included):

#
# Copyright (c) 1992, by Sun Microsystems, Inc.
#
#ident	"@(#)st.conf	1.6	93/05/03 SMI"

tape-config-list = "DEC     DLT2000", "Digital DLT2000 DLT", "dlt2000-data";
dlt2000-data = 1, 0x33, 16384, 0x21d, 4, 0x17, 0x18, 0x80, 0x81, 2;

name="st" class="scsi"
...

Excerpt from the st man page :

...
 The formal syntax is:
          tape-config-list = <triplet> [, <triplet> *];
     where
          <triplet> := <vid+pid>, <pretty print>,
               <data-property-name>
     and
          <data-property-name> = <version>, <type>, <bsize>,
               <options>, <number of densities>,
               <density> [, <density> ], <default-density>;

...
    <bsize> is the preferred block size of the tape device.  The
     value should be 0 for variable block size drives.
...

     <number of densities> is the number of densities  specified.
     Each  tape drive can support up to four densities. The value
     entered should therefore be between 1 and 4; if less than 4,
     the remaining densities will be assigned a value of 0x0.

     <density> is a  single  byte  hexadecimal  number.   It  can
     either  be  found  in  the  drive specification manual or be
     obtained from the drive vendor.

     <default-density> has a value between 0 and (<number of den-
     sities> - 1).
...

The extra DLT added in the "Digital DLT2000 DLT" string is added for
readability and it is also a nice to way to ensure that your entry
is correct (look at the output from boot -rv).



 6.4.1 Problem with zero block size under SunOS 5.3.

So why is the block size set to 16384 when the man page say :
"value should be 0 for variable block size drives" ?
Well - it's a bug in 5.3 - if you use 0 you will get divide by zero errors (!);
so the the bsize must be set to something else. However if you keep the
non-zero value and upgrade to 2.4 you will get problems - more on that
later. (Also refer to SunSolve bugid 1200807 for a long description of this).
 


 6.4.2 Halvard's setup for 5.3/2000.

Densities go from low to high and the last "2" in the dlt-data line sets
the default (/dev/rmt/0) device to use the 10GB uncompressed device (points
to 0x80). I think this makes good sense.

 6.4.3 DEC's setup for 5.3/2000.

Now lets look at a typical recommendation for 5.3 (DEC's old) 
which you are likely to find on the net. 
I think DEC's one is totally out of place ... ;-)
(DEC probably just moved their 4.1.x recommendation to 5.x without
 checking the format ...) :

tape-config-list = "DEC     DLT2000", "(nickname)", "magic-data";
magic-data = 1, 0x33, 16384, 0x21d, 4, 0x80, 0x81, 0x19, 0x18, 3;

 6.4.4 Halvard's vs DEC's 2000 setup - or why you should avoid DEC's setup.

and thus we can set up the following table:

 device      (aka)    Halvard's recommendation		DEC's recommendation
-----------------------------------------------------------------------------
/dev/rmt/0l (low)	  2.6 GB uncompressed		10 GB uncompressed
/dev/rmt/0m (medium)	  6   GB uncompressed		20 GB compressed
/dev/rmt/0h (high)	  10  GB uncompressed		20 GB compressed
/dev/rmt/0c (compressed)  20  GB compressed		 6 GB uncompressed
/dev/rmt/0  (default)	  10  GB uncompressed		 6 GB uncompressed

The table speaks for itself ;^) - among other things you get the 
6GB uncompressed mode when asking for compressed mode using DEC's
"recommendation".

I _know_ that the "native default" mode of the drive is 20 GB compressed;
but i prefer to only use compression when I ask for it. Your mileage
may vary, and if you want to change the "default device" from 
10 GB uncompressed to 20 GB compressed you should be able to 
do so by reading this paper ;^)



 6.5 Configuration file for 5.4/5.5.


First part of 5.4 st.conf (with just the 2000 as an example):

#
# Copyright (c) 1992, by Sun Microsystems, Inc.
#
#ident	"@(#)st.conf	1.7	93/12/20 SMI"

#
# Following entry below supports Metrum Tape Drives at any target.
# Remove the '#' character to really configure a Metrum Tape Drive.
# You can construct similar entries for other tape drives.
# Refer to st(7) man page for details.
#
#tape-config-list=
#        "Metrum", "Metrum VHS Cartridge", "metrum-data";
#metrum-data =1,0x36,1024,0x1639,1,0,0;

tape-config-list = "DEC     DLT2000", "Digital DLT2000 DLT", "dlt2000-data";
dlt2000-data = 1, 0x33, 0, 0x21d, 4, 0x17, 0x18, 0x80, 0x81, 2;

name="st" class="scsi"
...

As you will note there is only one change here - the block size is set to
zero as it should be according to the man page (see 6.3). This is the only
change (but a vital one - see below). Devices to use and so on is similar
to 5.3.


 
 6.5.1 Problem with non-zero block size under SunOS 5.4/5.5.

If you specify something else than zero for the block size under 5.4 this
gives some weird results. The drive behaves like a fixed record size device -
ie it only accepts output in the specified block size. This behaviour is
of course highly unwanted ;^). If you used the drive (or any other
third party drive defined in st.conf) under 5.3 and kept your st.conf
file when upgrading your drives will suddenly appear unusable. The fix is
to put in the zero as shown for DLT. If not changing the block size to zero
you will see error messages like these (example with tar) :

tar cvf /dev/rmt/0h .
a ./ 0 tape blocks
a ./helse2.sh 12 tape blocks
a ./Helsesjekk.doc 28 tape blocks
tar: write error: Invalid argument
tab% 
WARNING: /iommu@0,10000000/sbus@0,10001000/espdma@4,8400000/esp@4,8800000/st@5,0 (st5):
	write: not modulo 16384 block size.


( The block size problem (for both 5.3 and 5.4) is discussed to length under
  Sun's bugid 1200807 (SunSolve). If you read the notes on this bugid
  - beware that Legato use their own internal format for backup 
  (Networker/32Kb) and thus you should only use Legato's st.conf
  if you have Networker! )

This is a Solaris software bug - the drive itself will accept any block
size from 1 byte to 16 MB.



 6.6 To REEL or not to REEL.

If you get access to Quantum's papers and also in some other configuration
files you will notice that some of them do not use the REEL as a type.
Common other "device types" to use are "other SCSI drive" (0x36) for 5.x
and "Generic 1/2" Cartridge" (0x26/ST_TYPE_HIC) for 4.1.x. As all of these
are _generic_ drivers as is the REEL one i still prefer to use REEL as
originally recommended by DEC and I've noticed no unwanted behaviour using
REEL as the type. At least on Solaris 2.x (SunOS 5.x) i strongly prefer
the drive present itself as "REEL" instead of the rather vague 
"other SCSI drive".

 7. THOSE DRIVE OPTIONS - WHAT DO THEY MEAN?

from the 5.3 st man page:

     <options> is a bit pattern representing the  drive  options,
     as  defined in /usr/include/sys/scsi/targets/stdef.h.  Valid
     flags for tape configuration are:
              ST_VARIABLE        0x0001
              ST_REEL            0x0004
              ST_BSF             0x0008
              ST_BSR             0x0010
              ST_LONG_ERASE      0x0020
              ST_KNOWS_EOD       0x0200
              ST_IQIC            0x0002
              ST_UNLOADABLE      0x0400
              ST_LONG_TIMEOUTS   0x1000

part of the /usr/include/sys/mtio.h file in 5.3:

#define	MT_ISQIC	0x32		/* generic QIC tape drive */
#define	MT_ISREEL	0x33		/* generic reel tape drive */
#define	MT_ISDAT	0x34		/* generic DAT tape drive */
#define	MT_IS8MM	0x35		/* generic 8mm tape drive */
#define	MT_ISOTHER	0x36		/* generic other type of tape drive */



from the 4.1.4 /usr/sys/scsi/targets/stdef.h file:

/* Defines for supported drive options */
#define	ST_VARIABLE		0x001	/* supports variable length I/O */
#define	ST_REEL			0x004	/* 1/2-inch reel tape drive */
#define	ST_BSF			0x008	/* Supports backspace file */
#define	ST_BSR			0x010	/* Supports backspace record */
#define	ST_LONG_ERASE		0x020	/* Long Erase option */
#define	ST_AUTODEN_OVERRIDE	0x040	/* Auto-Density override flag */
#define	ST_NOBUF		0x080	/* Don't use buffered mode */
#define	ST_NOPARITY		0x100	/*
					 * This device cannot generate parity,
					 * so don't check parity while talking
					 * to it.
					 */

#define	ST_KNOWS_EOD		0x200	/* knows when EOD has been reached */
#define	ST_QIC			0x202	/* QIC tape drive knows EOD */
/*
 * old defines for the options flag - not supported anymore
 * here for historical reference only.
 */
/* was ST_NO_FSR- Sysgen only	0x020	/* No forwardspace record */
/* was ST_NODISCON- Sysgen only	0x080	/* No disconnect/reconnect support */
/* was ST_NO_QIC24- Sysgen	0x100	/* No QIC-24 (for Sysgen) */
/* was ST_NO_POSITION- ignore	0x400	/* Inhibit seeks flag */


and some more from the 4.1.4 /usr/sys/scsi/targets/stdef.h file

#define	ST_TYPE_CDC		0x20	/* CDC - (not tested) */
#define	ST_TYPE_FUJI		0x21	/* Fujitsu - (not tested) */
#define	ST_TYPE_KENNEDY		0x22	/* Kennedy */
#define	ST_TYPE_HP		0x23	/* HP */
#define	ST_TYPE_HIC		0x26	/* Generic 1/2" Cartridge */
#define	ST_TYPE_REEL		0x27	/* Generic 1/2" Reel Tape */

#define	ST_TYPE_EXABYTE		0x28	/* Exabyte */
#define	ST_TYPE_EXB8500		0x29	/* Exabyte */
#define ST_TYPE_PYTHON  	0x2c	/* Archive Python DAT */



  8. OTHER DLT'S - STACKERS (2500,2700,4500,4700) AND XT'S
 	(2000xt,2500xt,2700xt).

I have no experience with these drives whatsoever - but for these drives 
my configuration files should still be usable.

The 2500/2700 and 4500/4700 are 2000's and 4000's with a 5 or 7 cartridge
auto-loader.
The 2000xt drives are a newer version of the 2000 with expanded capacity
(15 GB uncompressed/30 GB compressed).

If my entries do not work out of the box just do a probe-scsi as mentioned
earlier to see what the drive presents itself as and rewrite the 
configuration file. Remember that spaces _are indeed_ very significant!).

At least the DLT 2700 have been tested by others using my configuration
files and also all of Quantum's pages use the same entry for eg a
DLT 2000 and a DLT 2700.

The x700 loaders have LED's similar to the 2000/4000 and the x500 loaders
use an LCD display.




 9. CompacTape III,CompacTape IIIxt and CompacTape IV.

The CompacTape III is a 4-inch, gray (almost brown I would say)
cartridge containing 1100 feet of 1/2 inch magnetic metal particle tape. 

The CompacTape IV is a 4-inch, black cartridge containing 1800 feet of
of 1/2 inch magnetic metal particle tape.

The 2000 normally uses the III tape and the 4000 normally the IV tape.
Do _not_ use the IV tape in the 2000. The III tape can be used in the
4000 and if you are going to mix III and IV tapes in the 4000 there are
a couple of things noting.

The 4000 will automatically recognize the tape so if you try to write in
40 GB/compressed mode on a III tape you will get compression but not in
40 GB mode. The drive will write in 20 GB/compressed mode. The same
thing happens when using a IV tape and trying to write on it in one of the
"older" modes (80 and 81 codes); the drive writes the tape in "IV mode" -
ie 20 GB uncompressed or 40 GB compressed. So please use the
correct devices _and_ the correct tapes to avoid confusion.

The DLT 4000 can write 2.6, 6.0 and 10 GB formats (rewrite your 
configuration file for doing this ;-) - but you do have to use the
correct cartridges).

(The above section will be rewritten).




10. NOTE ON MICROCODE/FIRMWARE UPDATES.

If you do not get the drive to work at all or you experience other 
unexplainable problems you _might_ have a firmware problem. The DLT's
have a Flash EEPROM which will allow you to load new microcode to the
drive from tape. Contact your vendor if you need a microcode update.

Your microcode revision might show (or might not - depending on what
your vendor/reseller have chosen to implement) when using the "probe-scsi" 
command. 

If you have a newer drive (ie a Quantum made one) it _should_ show -
Rohbeck for the last time ;-) :

" The version will always show. The vendor/product ID can be
  changed, but the version will always show up, at least the first
  4 bytes, which identify formatter (first 2 bytes) and SCSI controller
  revision (3rd and 4th byte). The formatter version is a hex number, the
  controller version is the firmware rev. in hex, e.g. 1E for V30. ".

The Quantum papers mentions the following restrictions for use with Sun's:

DLT 4000 series:	firmware has to be V25 or higher.
DLT 2000 series:	firmware has to be V10 or higher.
DLT 2000xt series:	no firmware restriction.




11. WRITING YOUR OWN ENTRIES FOR THIRD PARTY TAPE DRIVES.

Reading this paper should enable you to configure other third party drives as
well. In principle you will have to have following at hand:

* the string it presents itself as (or VID + PID as it is put).
	- do a probe-scsi to get this or you might try utilities as
	  such as scsiping.

* the density codes and capabilities (ST_VARIABLE and such) for the drive.
	- get them from your manual,hardware vendor or the net.
	- decide on how you want the drive to behave and configure
	  it accordingly to this; ie if you want the drive to just
	  use one density go ahead ;-)

* speed and capacity of the drive.
	- for testing your configuration and puzzle around with the
	  dump command if you are using 4.1.x


12. CORRECT USE OF THE "probe-scsi" COMMAND.

From Sun: 

>We have documented this carefully in the OpenBoot 3.x Command Reference
>manual (802-3242-10).  It states:
>
>	"If you boot the OS, exit from the OS into OBP without resetting the 
>	 system, then use some OBP commands, the commands might not work as 
>	 expected.  In this case, you may have to power cycle the system to 
>	 restore normal operation."
>
>The specific example given in the manual which WILL FAIL is probe-scsi.  
>We say "reset the system first (reset-all), then invoke the (probe-scsi) 
>command." >

so set "setenv auto-boot? false", then do a "reset-all" or "reset" and then a 
"probe-scsi" ("probe-scsi-all") would be the correct way to do it an 
Ultra and possibly other machines. Remember to do a "setenv auto-boot? true" 
when done.



13. PLANNED EXTENSIONS OF THIS DOCUMENT.

* something more on use of the different types of tape in the different drives.
* something on tuning for optimal performance in Solaris 2.4/2.5 (man st!).
* some small note on use of the "mini-library".
* something specific on patches (though I'm not sure yet if I will include
  this?)

14. DLT COOKBOOK AVAILABILITY ON THE NET.

The latest version of this document is available by anonumous ftp from 

ugle.unit.no	: /info/unix/DLT_on_Sun.txt
ftp.rahul.net	: /pub/lps/hard-disk/name_to_be_announced.

A html-version is planned.

 APPENDIX A - SOURCES.

sources of information:

- DLT 2000 Series Magnetic Tape Product Manual (EH-TH4XX-IM. A01) from DEC
- DLT 4000 Series Magnetic Tape Product Manual (EH-TH5XX-IM) from DEC
- Sun's man pages
- SunSolve - BugId 1200807 on problems with the st driver
- my own testing

- from Quantum':
	* "0.5 inch Cartridge Digitial Linear Tape (DLT) Drives" product paper.
	* "DLT2000/DLT2000xt/DLT2500/DLT2500xt/DLT2700/DLT2700xt Installation/
	  Sun Sparcstation/Solaris 2.3" QT00007.A01 application note.
	* "Installing a DLT 4000/Sun Sparcstation/Solaris 2.3" QT00009.A00.
	* "DLT4000/DLT4500/DLT4700 Installation/
	  Sun Sparcstation/Solaris 2.4" QT00013.A00 application note.
	* "Installing a DLT 2000/DLT2000xt /Sun Sparcstation/ Solaris 2.4"
	  QT00011.B01 application note.
	* "DLT2000/DLT2000xt/DLT2500/DLT2500xt/DLT2700/DLT2700xt Installation/
	  Sun Sparcstation/SunOS 4.1.3" QT00006.A01 application note.
	* "DLT4000/DLT4500/DLT4700 Installation/
	  Sun Sparcstation/SunOS 4.1.3" QT00008.A01 application note.

- helpful comments and such from the people in Appendix B.




 APPENDIX B - THANKS.

to the following persons for very valuable input :

Ralf-Peter Rohbeck, Quantum GMBH	rrohbeck@qntm.com
Charlie Cassidy, Quantum Corporation	ccassidy@tdh.qntm.com
Espen Martinsen, Skrivervik Data as	espen.martinsen@sdata.no
James C. Anderson, Oberlin College	anderson@ocaxp1.cc.oberlin.edu
Luke Mewburn, Telstra Corporation	lukem@telstra.com.au
Asle Vestvik,Adresseavisen as		Asle.Vestvik@CCMAIL.telemax.no		


 APPENDIX C - LEGAL NOTICE.

Copyright (c) 1995,1996 Skrivervik Data AS.

Permission to use, copy, and distribute this documentation for any purpose 
and without fee is hereby granted, provided that the above copyright notice 
appear in all copies, that both that copyright notice and this permission 
notice appear in supporting documentation, that this document is not 
modified, and that the name of Skrivervik Data is not used in advertising 
or publicity pertaining to distribution of the software without specific, 
written prior permission. Skrivervik Data makes no representations about 
the suitability of this documentation for any purpose. It is provided "as 
is" without express or implied warranty.
All other product names are copyrighted by their various owners.

