--
Ed Bailey, Information Systems and Networks
(contracted to: National Institute of Environmental Health Sciences)
Research Triangle Park, NC 27709
Internet: bailey_at_niehs.nih.gov
BITnet: BAILEY_at_NIEHS.BITNET
Voice: (919)361-9422, extension 239
FAX: (919)361-9136
From: "Tim W. Janes" <janes_at_signal.dra.hmg.gb>
Hi,
I attach a very old (Oct 94) DLT FAQ - I do not know the current
status of this faq. Larry who maintained it left DEC to work for
quantum.
I also attach a README of a OSF/1 program to control the loader I do
not have a record of where I obtained it but there is an authors email
good Luck
Tim.
+------------------------------------------------------------------------+
DLT.FAQ
+------------------------------------------------------------------------+
Frequently Asked Questions about DLT Tape Drives
Written and Maintained by:
Larry Kaplan
Manager, Firmware Development, DLT Products
Quantum Corporation
Shrewsbury, MA, USA 01545
E-MAIL: lkaplan_at_tdh.qntm.com
Voice: (508) 770-6872
Technical questions only, please
+------------------------------------------------------------------------+
Last Updated:
3-Oct-1994 - New to this posting:
New contact address
Many new Q/A. Appended to the end of the previous version.
30-Sep-1994 - New contact information
29-Aug-1994 - New to this posting:
DLT Product Software Connectivity Chart
Pointer to application notes for certain attachments
+------------------------------------------------------------------------+
Q: I'm thinking of buying a DLT. What is available and what are the
specifications ?
A: Presently three generation of product are available.
Product Name Comp? Capacity (uncomp) User Data Rate (Uncomp)
+-------------+-------+-------------------+----------------------+
TZ85/THZ01 N 2.6 GB 800 KB/sec
TZ86/THZ02 N 6.0 GB 800 KB/sec
TZ87/DLT2000 Y 10.0 GB 1.25 MB/sec
Q: Do these product support previous formats ?
A: Yes, refer to table below:
Product Name Format R/W
+--------------+------------+--------------+
Tx85/THZ01 TK50 R only
TK70 R only
TZ85 R/W
Tx86/THZ02 TK50 R only
TK70 R only
TZ85 R/W
TZ86 R/W
TZ87/DLT2000 TK50 R only (not supported on TZ87N or
DLT2000)
TK70 R only (not supported on TZ87N or
DLT2000)
TZ85 R/W
TZ86 R/W
TZ87 R/W
Q: Is fast/wide SCSI available ?
A: Presently, all three products support 8-bit, 5 MB/sec, SCSI, both
single ended and differential.
Q: What products are under development ?
A: There's lots of bandwidth left in the technology. Currently,
prototypes are under test for the DLT4000, which increases
capacity to 20 GB (uncompressed), increases the User Transfer
Rate (uncompressed) to 1.5 MB/sec, and provides support for
10 MB/sec (fast) SCSI, single-ended and differential.
Other advancements will be announced in due time.
Q: I've recently connect a DLT to my system. It's unbelievably slow.
What gives ?
A: It's common for a host to disable the drive's internal cache
if it doesn't recognize the product name string. If this is
true, the DLT's performance can be reduced to the sub 100KB/sec
range.
A second possibility is the record size being used by the host.
The DLT 2000 is especially sensitive to record size. In general,
the bigger, the better. We recommend 32K, or even 64KB records
if possible (up to 16MB records are supported). In general,
any record size greater than 8KB should result in a
bottleneck-free tape drive. Any record size less than 8KB will
give performance problems. Many software packages default to
512 byte records. This will result in throughput in the
100-200 KB/sec range.
Q: The performance isn't bad, but I'm not getting the full rating
of the tape drive.
A: Many other factors contribute to the actual performance as seen by
a user. Host speed, host adapter, bus configuration, host
software, disk characteristics, are all bottleneck considerations.
Q: What Platforms and Software Products (Non DEC) Support DLT
A: See Charts below:
Novell/NLMs
+====================================================================+
Product DLT2000 DLT2500 DLT2700 DLT4000
+--------------------------------+--------+--------+--------+------+
Arcada Backup Exec Yes Yes Yes Q3
Avail - HSM Yes Yes Yes Q4
Cheyenne ARCserve NLM 4.05 Yes Yes Yes Q3
Cheyenne ARCserve NLM 5.01 Yes Yes Yes Q3
Conner - HSM Yes Yes Yes Q4
Legato - Networker Yes Yes Yes Q3
NovaStor NovaNet Yes Yes Yes Q4
Palindrome Backup Director Yes Yes Yes Q4
Palindrome Network Archivist - HSM Yes Yes Yes Q4
Systems Enhancement Total Recall Yes Yes Yes Q4
UNIXware
+====================================================================+
Product DLT2000 DLT2500 DLT2700 DLT4000
+--------------------------------+--------+--------+--------+------+
Cheyenne ARCserve/Open 1.1 Q4 Q4 Q4 Q4
Legato UNIX Yes Yes Yes Q3
NovaStor - NovaVault Yes Yes Yes Q195
SCO
+====================================================================+
Product DLT2000 DLT2500 DLT2700 DLT4000
+--------------------------------+--------+--------+--------+------+
Cheyenne ARCserve/Open 1.1 Q4 Q4 Q4 Q4
NovaStor - NovaMarch Yes Yes Yes Q195
DOS
+====================================================================+
Product DLT2000 DLT2500 DLT2700 DLT4000
+--------------------------------+--------+--------+--------+------+
Arcada - Backup EXEC for DOS Yes No No Q4
Cheyenne ARCsolo for DOS Yes No No Q4
NovaStor - NovaBack for DOS Yes Yes Yes Q4
Windows
+====================================================================+
Product DLT2000 DLT2500 DLT2700 DLT4000
+--------------------------------+--------+--------+--------+------+
Arcada - Backup EXEC for Windows Yes No No Q4
Cheyenne ARCsolo for Windows Yes No No Q4
NovaStor - NovaBack for Windows Yes Yes Yes Q4
OS/2
+====================================================================+
Product DLT2000 DLT2500 DLT2700 DLT4000
+--------------------------------+--------+--------+--------+------+
Cheyenne ARCsolo for OS/2 Q4 Q4 Q4 Q4
NovaStor - NovaBack for OS/2 Yes Yes Yes Q4
Q: Can I attach a DLT2000 to a HP9000-700 ?
A: Yes - Mail to the FAQ maintainer and request the appropriate
application notes.
Q: Can I attach a DLT2000 to an IBM RS/6000 AIX 3.2 ?
A: Yes - Mail to the FAQ maintainer and request the appropriate
application notes.
Q: Can I attach a DLT2000 to a SUN SPARC (Solaris 2.3) ?
A: Yes - Mail to the FAQ maintainer and request the appropriate
application notes.
Q: Can I attach a DLT2000 to a SUN SPARCSTATION SunOS 4.1.3 ?
A: Yes - Mail to the FAQ maintainer and request the appropriate
application notes.
Q: I understand that there is a directory of data objects stored at the
start of the tape. If I issue a SCSI LOCATE command, does the drive
go back to BOT to access this directory and then position? What is
the worst case locate time?
A: The directory is read into the drive's memory during the Load
process and accessed from there (and updated as needed; the updated
directory is written back on the unload.) Typical worst case Locate
time is about 100 seconds; there may be some cases that will be longer
due to retries, but that is not normal.
Q: Which SCSI commands will utilize the data object Directory and
provide the best file search performance?
A: The SCSI LOCATE command will give the best possible performance,
especially relative to a Space by filemarks/Space-blocks combination.
If the application simply wants to get to a particular filemark
(versus a data block), then the Locate command will give equivalent
performance to a Space-filemarks command. The ideal situation is to
be able to specify the ultimate destination that the application is
trying to get to on the media with a single command, and the Locate
command is the most general and effective way to do that.
Q: Will any SCSI Commands lose performance without any filemarks
on the tape?
A: The answer is no. In fact, without any filemarks on tape, a
Space-blocks command becomes almost equivalent to a Locate cmd
(except the one uses a relative count, and the other an absolute
address)
Q: The IBM IDRC compression algorithm checks to make sure that it is not
expanding data. What algorithm is used in the DLT and is it prone to
failure with precompressed data? What does the compression algorithm do
to the error rate?
A: An LZ type algorithm is used. It does not "fail" per-se, but highly
compressed data will expand somewhat. (IDRC compressed data usually
gets compressed slightly more by DLT2000). I have seen 5% expansion
when "compressing" random data on the DLT2000. The error rate is
media based, so compression on/off does not affect it.
Q: I understand that the drive will stream with data blocks that are
at least 8KB in size. Does compression affect this? Does compression
affect data packing and efficient use of tape?
A: Yes. But tape streaming is not the real issue; whether the tape drive
can keep up with the rate that the host can pump data to it or not is.
With high compression ratios (above 3:1) the drive's data compressor
(or the SCSI bus for that matter) may not be able to keep up with
the data rate into the drive cache buffer to keep the drive streaming.
In this scenario, as the cache gets full enough, the drive will be
started, but will be able to empty the cache faster than compressed
data can be put into it. Under these conditions, an 8K block size
may not be enough to ensure streaming performance at all compression
ratios.
The drive will always do data packing, whenever appropriate, so
compression does not affect that. Compression naturally makes for
more efficient use of the tape media.
Q: Is logical space truely sequential? Does compression affect the logical
space?
A: The device handles "defects" in a way that is completely
logically transparent. The Locate command deals with logical
blocks (whether BT flag is set or clear) so it skips over
blocks and filemarks in a logical fashion. The only time a
defect is not transparent is when a hard read or write error
occurs. A hard read error does not normally prevent accessing
data (if any) on the media beyond the defect.
Compression has no affect on the logical space and the host can still
logically position to any block on the media.
Q: Is it reasonable to always use compression? Are there Performance
issues? How is data compression selected?
A: In general, an applications will benefit from enabling data compression.
The exception is when data has already been compressed
with a Lempel-Ziv (or an even more powerful algorithm) compression
method. Such compressed data, or very random data (including
encrypted data), will likely expand slightly (~5%). If in doubt,
and if there is a significant amount of such data, run some tests
to see what sort of compression rates you actually get (use Log
Sense Compression Status page to get compression ratios).
If the data is compressing, throughput will increase roughly in
direct proportion to the compression ratio from the native data
rate, until the drive's maximum is reached.
If a section of tape has compressed data, the front panel will indicate
when the drive is reading compressed data. The DLT drive will
automatically match to the way the data was written and decompress
whenever compressed data is requested.
Compression can be turned on/off at any time when writing. There
are basically 4 ways to do this: Mode Select Device Configuration
Page, Mode Select Compression Control Page, Mode Select VU density
code values, and the front panel (which overrides any SCSI selection).
Q: In compressed mode, if 5 16kbyte blocks are written will logical block
address increment by 5? etc. What about accessing a non-zero offset of
the data stream?
Whether the blocks are written in variable or fixed block
mode, compressed or uncompressed, each block is a distinct logical
block on the media. The Read Position command will reflect this
and the effect of compression is transparent.
As for "seeking into a nonzero offset of the data stream" that
is a filesystem function and at the SCSI level would have to be
decomposed to some kind of Space/Locate command (possibly) and
then issuing Read command(s). The host would then ignore data
until the desired byte offset is reached, and start returning
data from that point to the application. SCSI sequential devices
do not have the capability to return data starting with a byte offset.
Q: How much space does a Write Filemarks command use?
A: It could use 0 to 8KBytes. A Write Filemarks (WrFMs) command of
0 will force any data in the cache onto tape. If the last physical
block is only partially full it must still be "closed out" and
flushed. This normally results in an insignificant capacity loss,
unless WrFMs zero (alias a "flush") commands are issued very frequently.
If this is done, it would also impact throughput performance
because of the flush operation. A WrFMs zero will *not* result in
any logical block of itself (only what it flushes from previous
write commands). Again, it is equivalent to a "cache flush".
A WrFms of 1 will cause the current physical block to be closed and
flagged as containing 1 filemark, so this filemark takes up from
zero to 8K bytes (however much unused space was left in the 8K
physical block). After writing 1 filemark, consecutive filemarks
written right after that (i.e. sequential filemarks) will each
use 1 physical block (8KB).
Q: What happens after a powerfail or SCSI RESET during writing? Can we
append to the tape?
A: On a SCSI Bus RESET, all data that is in cache is flushed to the
media. This might result in a partial block on media, especially
with very big blocks (ex: 10 MB). A power failure will naturally
clear the device (and cache) since there is no provision for
battery back-up within the DLT drive.
Once a Write Filemarks with count=0 completes, the media is guaranteed
to be synchronized with the cache (i.e. cache is flushed, all data
and filemarks up to the flush are now on tape). A bus Reset before
the WrFMs zero completes will not kill the flush itself. A power
failure will. The application can Space to EOD and check position
to see if all data got flushed, but since the WrFMs zero did not
complete (due to the powerfail) some data might be missing, and
there might be a partial block. However, the application can always
go back to the position of the last *successful* flush.
Q: For fixed block mode, what is the suggested block size?
A: 16 KB or larger for good performance and compression rates. Between
8 KB and 16 KB performance should be okay. But, below 8 KB device
throughput starts to fall off, so 8 KB or higher should be used
if possible. This applies to fixed and variable block modes.
Q: What are the number of blocks that can fit on tape?
A: The number of blocks you can fit on a particular cartridge will vary.
Generally you can take the rated capacity and simply divide by the
block size you plan to use. If compression is used, the number of
blocks can only be roughly estimated, unless the compression ratio
with that particular data is uniform and well characterized.
Q: What happens when you try to select the drive during powerup, or during
tape load/unload?
A: After powerup, the drive will not respond for about 1 second to
any Selection attempts, while the drive's Power-On Self Tests (POST)
checkout the SCSI interface hardware. After that, Selections will
be responded to but any CDB will receive a BUSY Status, for the next
10 or so seconds. Then commands will be responded to normally,
although the media might not be ready so media access commands will
generally fail with a NotReady Sense Key.
For load/unload, after an Unload is initiated, the media is not ready.
After a Load command (Imm=0) completes the media will be at BOT and
ready for media access commands.
Q: How is media shelf life defined and specified?
A: Shelf life is 10 years min. _at_ 20 degC and 40% RH. After 500k passes
the tape should continue to function normally, unless it is being used
in an evironemnt with heat, humidity or contamination levels beyond
those recommended.
Q: What is a "tape pass"? When do you recommend retiring tapes?
A: A pass is the media passing over the head once. A full pass would
mean going from one end of the tape to the other.
At this point we cannot suggest a number of passes after which a
cartridge should be retired, because the media does not seem to
wear out and actually improves with use. We have tested the media
up to 500,000 passes without degradation and use this number as
our specification, even though a much larger number of passes could
be attained.
Q: How is the error rate calculated? How many retries are assumed? Does
the error rate apply to virgin tape or to tape which has seen 500,000
passes? Does it apply with compression on?
A: Error rate is calculated based on rewrite, over-write, ECC's and
re-reads. The error rate for virgin vs. used tape is expected tobout the same. The media tends to improve with usage and the
media error rate applies to raw data on the media, so compression
is not a factor.
--
--
+---------------------------------------------------------------------------+
| Larry Kaplan | |
| Quantum Corporation | |
| Shrewsbury, MA 01545 USA | |
| Voice: (508) 770-6872 (office) | |
| (508) 770-6721 (lab) | |
| FAX: (508) 770-2869 | |
| lkaplan_at_tdh.qntm.com (work/professional) |
| kaplan_at_ultranet.com (home/personal) |
+---------------------------------------------------------------------------+
6 April 1995
Hello!
You are now the proud owner of my tape loader control utility. I wrote
this program to permit the amanda network backup software (highly
recommended: check out ftp.cs.umd.edu, in /pub/amanda for the latest copy.)
to directly control our DEC TZ877 seven-slot DLT loader. It's been in use
now for over a month with nary a hiccup, so I thought I'd give it to others
to break. ;-)
Random Notes:
o This program uses Wolfgang Barth's SCSI access library to talk to the
loader via /dev/cam. The original version of Wolfgang's library can
be obtained from: speckled.mpifr-bonn.mpg.de in
/pub/scsi/scsilib.tar.gz. However, since Wolfgang wrote this code to
run under DEC Ultrix, and we're running DEC OSF/1 (now called Digital
Unix), some changes had to be made. They're minor, but I'm making
available a modified version of scsilib.tar.gz for those that don't
feel the need to hack it on their own...
o Makefile? We don't need no steenkin' Makefile! To build this
program, Issue the following command:
cc loader.c -o loader -L<libscsi-location> -lscsi
Where <libscsi-location> is the location of libscsi.a.
o Speaking of locations of things, I copped out and simply made a
directory called "loader-src" on the same level as the directory
(called "scsilib") that held Wolfgang's code. The only artifact of
this layout are the two #includes in loader.c that refer to
"../scsilib/<whatever>". So if you set up things differently, those
#includes are going to have to change.
o The program as written looks at the name it was invoked under in
order to determine the name of the loader it is to control. The name
of the program should look something like:
foonly-loader
Where "foonly" is the name of the tape device. This device is
expected to reside in /dev, but this can be changed. So basically
what it does is to grab the part of the name prior to "-loader",
prepend "/dev/" to it, and then get the bus and target (aka SCSI id)
from that device's minor number. This is probably completely OSF/1
dependent, so if it doesn't work on your non-OSF/1 machine, I told ya
so!
Anyway, I ended up plopping the executable "loader" in
/usr/local/bin, and then symbolically linking nrmt0h-loader and
nrmt0m-loader to it. This way, you can control different loaders
with only one copy of the program. Amanda users: Note that the
device name the program returns is what amanda will use for backup
purposes, so you need to get the name just right, or your tape
density/rewind stuff will be gronked.
o Wolfgang's library routines use a locking file to control access to
/dev/cam. In order to make *anything* that uses his routines work,
you need to create a file called "cam.lock" in /usr/local/etc (touch
works fine). This file will need read/write permission for whoever
will be using the loader program. Can you move the location of the
file? I don't see why not, but I didn't bother.
o As noted above, this program was written to control a DEC TZ877. If
I was a betting person, I'd bet that it would work on a DEC TZ875,
and the various OEM versions that Quantum (who bought the DLT
business from DEC recently) produces. I tried to make the code as
general purpose as possible, so other loaders that:
- Dedicate a SCSI LUN (Logical Unit Number) to the loader
mechanism,
- Dedicate one or more LUNs to the tape transport(s)
will probably work. However, be aware that loaders with multiple
access arms (the thingies that actually move the tape from a slot to
a tape transport) may have problems, as the code will only try to use
the first access arm. Also, the code assumes that there's only one
tape transport, so loaders that have multiple transports won't work
on this as written. If anyone out there wants to try to rectify
this, let me know. In addition, since this code returns the device
name it cobbled together from the program name, loaders that make
their transports available as seperate devices won't be able to use
this code, either. If you want to modify it, let me know, which
brings up the issue of...
o Support? Well, I'll be here if someone wants to donate a
patch/enhancement to be integrated, but I can't do too much in the
way of hand-holding. You're pretty much on your own, gang...
Good Luck!
Ed Bailey, Information Systems and Networks
(contracted to: National Institute of Environmental Health Sciences)
Research Triangle Park, NC 27709
Internet: bailey_at_niehs.nih.gov
BITnet: BAILEY_at_NIEHS.BITNET
Voice: (919)361-9422, extension 239
FAX: (919)361-9136
From: "Edward C. Bailey" <ed_at_moocow.niehs.nih.gov>
>>>>> " " == Massimo CARBONI <carboni_at_hpserver.lnf.infn.it> writes:
> Hi Ed, I'm a DEC-Unix & HP-UX administrator, up to now I've manage 20
> systems (workstation and servers). We've a DLT with loader TZ877 from
> DEC, for network backup and data analysis. We would like to use this
> system as a random access system; DEC people in Italy is not able to
> give us any support to do this. I had submitted yesterday an e-mail to
> the distribution list osf-managers and a got your address. We don't
> have any documentation, only the loader. We need a simple software to
> access this system.
[snip]
Hello! I just read your message on the osf list, and responded (perhaps
it's gotten to you already). I won't repeat myself here - basically I
pointed you to a product support manual for the TZ877, and invited you to
get a copy of my loader program (which you've already done!)...
> With this "loader" program is it possible to load a generic tape from
> the loader TZ877 ? This is the most important improvement for us. After
> this I'm also interested to install your amanda software (I've 130 GB of
> disk space).
I'm not exactly sure what you mean by a "generic tape". The loader
mechanism doesn't really care what is on the tape, only if a particular
slot has a tape in it or not. So yes, my loader program will load any kind
of tape from any slot. To give you an idea of what it can do, here's the
usage screen from it:
usage: nrmt0m-loader [-slot|-info|-reset|-eject|-status] [slot-id]
-slot slot-id Loads the tape stored in "slot-id" into the tape drive
("slot-id" may be any loader-specific ID from -status, or
one of the words first, last, next, prev, and current.)
-info Writes to stdout the current slot-id, the number of slots,
and a one if the loader can go backwards, a zero if it cannot
(ie, a gravity stacker)
-reset Resets the loader to a known state - the tape in the first
slot is loaded
-eject Ejects the currently loaded tape
-status Writes to stdout a summary of the contents of the loader
and the tape drive
All commands (except -status) write the current slot-id to stdout. With the
exception of -info, this is followed by the tape drive's device filename, or
an error message indicating the reason the command could not be completed.
Return Codes:
0-Success, 1-Non-fatal Error (Trying to load an empty slot, etc.), 2-Fatal Error
Basically, this code was written to interface directly with the amanda
network backup software, so every command (except -status) is designed with
that in mind. I added -status as a nice human-readable command...
As far as amanda goes, it isn't "mine", it's software written by some
people at the University of Maryland. We've been using it for some time,
and are generally pretty happy with it. If you need a network backup
package, you really should give amanda a try. I think its' design is
better than many of the commercial packages available...
If there's anything else you need to know, feel free to send me mail...
Ed
--
Ed Bailey, Information Systems and Networks
(contracted to: National Institute of Environmental Health Sciences)
Research Triangle Park, NC 27709
Internet: bailey_at_niehs.nih.gov
BITnet: BAILEY_at_NIEHS.BITNET
Voice: (919)361-9422, extension 239
FAX: (919)361-9136
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> End Replies <<<<<<<<<<<<<<<<<<<<<<<<<<
Received on Thu Aug 03 1995 - 15:09:14 NZST
This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:45 NZDT