Executive Summary: I was unable to get our new DEC DLT tapedrive
to work well. Although some problems remain
this message includes what we did to get reasonable
performance and excellent reliabilty.
The question:
I have the new DEC DLT drive (model TZ87N) and have been unsuccessful
getting it to work reasonably efficiently on a SUN SPARC running 4.1.3
with tar. Tapewrites are stunningly slow.
What am I doing wrong?
The device is set for SCSI 4, I am using /dev/st0
I added the following entry to st_conf.c and rebuilt the kernel
{
"DEC DLT TZ87", 15, "DEC ' Product 'TZ87", ST_TYPE_HIC, 16384,
"DEC DLT TZ87", 15, "DEC ' Product 'TZ87", ST_TYPE_HIC, 16384,
(ST_VARIABLE | ST_BSF | ST_BSR | ST_KNOWS_EOD),
400, 400,
{ 0x80, 0x81, 0x19, 0x18},
{ 0, 0, 0, 0 }
},
Message at boot looks like this:
sulu vmunix: st0: <Vendor 'DEC ' Product 'TZ87 (C) DEC'>
========================================================================
Current Status:
Here's where I'M at:
The following worked pretty well when shoved into
/sys/scsi/targets/st_conf.c and the kernel was rebuilt:
/* TZ87 10Gb DLT Streaming w/Compression Cartridge tape drive */
{
"DEC TZ87 10Gb Cart. DLT Streaming w/Compression", 12 ,
"DEC TZ87",ST_TYPE_DEFAULT, 8192,
(ST_BSF | ST_VARIABLE | ST_LONG_ERASE | ST_KNOWS_EOD),
5000, 5000,
{ 0x17, 0x18, 0x80, 0x81 },
{ 0, 0, 0, 0 }
},
What do I mean by "pretty well"? I mean piping files and thence into
tar for backups doesn't work BUT using nfs for backups works OK. Note:
I am using the stock Sun tar.
I tried about 5 variations on the above but that's the one I settled
on (for no particular reason).
(Note: st04 is kind of nonstandard but the machine involved has 2
other tapedrives already installed and only one SCSI interface).
# INFORMATION: The TK87 emulates 2 other drives and has both non-compressed
# and compressed modes.
#
# This drive is rst04 - TK85 (2.6GB)
# rst11 - TK86 (6.0GB)
# rst19 - TK87 (10 GB)
# rst27 - TK87 (20 GB - compressed)
#
and although this works:
tar cBhf /dev/nrst27 /biostat/pcnfs
this sort of thing, which worked for the Exabytes for YEARS, does not:
rsh atom "(cd /biostat ; tar cBhf - pcnfs )" | compress 1> /dev/nrst19
Backups and restores are swift like a flowing river via NFS so I am actually
quite happy and am no longer actively pursuing the problem.
====================================================================
Replies:
Norman_Hill@uncg.edu
Gary Smith
phil@cgrg.ohio-state.edu
jeffw@triple-i.com
Nate-Itkin@ptdcs2.intel.com
Jeff Wasilko
geigermp@nsd.fmc.com
Other useful facts:
DEC's storageworks homepage has some good support info on the drive but if
you contact them it's better to use email (we played quite a bit
of phone tag).
http://www.quantum.com has some stunningly useful info on the drives,
practically a tutorial on tapedrives and Unix kernels.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:52 CDT