More info (including DLT autochangers) in the comp.arch.storage FAQ.
Path: nntp-server.caltech.edu!news.claremont.edu!elroy.jpl.nasa.gov!lll-winken.llnl.gov!uwm.edu!cs.utexas.edu!news.sprintlink.net!worf.qntm.com!root
From: lkaplan@tdh.qntm.com (Larry Kaplan)
Newsgroups: comp.arch.storage
Subject: DLT FAQ as request - needs updating, maybe I'll get to it someday - dlt.faq [1/1]
Date: 13 Apr 1995 18:27:41 GMT
Organization: Quantum Corp.
Lines: 437
Message-ID: <3mjqet$cmn@worf.qntm.com>
NNTP-Posting-Host: sparfy.qntm.com
Mime-Version: 1.0
Content-Type: multipart/mixed;
Boundary="*-*-*- Next Section -*-*-*"
X-Newsreader: WinVN 0.93.14
--*-*-*- Next Section -*-*-*
--
--
+-----------------------------------------------------------------+
| Larry Kaplan | |
| Quantum Corporation | |
| Shrewsbury, MA 01545 USA | |
| Voice: (508) 770-6872 (office) | |
| (508) 770-6721 (lab) | |
| FAX: (508) 770-2869 | |
| lkaplan@tdh.qntm.com (work/professional) |
| kaplan@ultranet.com (home/personal) |
+-----------------------------------------------------------------+
--*-*-*- Next Section -*-*-*
Content-Type: Application/octet-stream; name=dlt.faq
+------------------------------ Start Of Post ---------------------------+
+------------------------------------------------------------------------+
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@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. @ 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 to
be about 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.
+------------------------------- End Of Post ----------------------------+
--*-*-*- Next Section -*-*-*--
1,,
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id ; Wed, 10 May 1995 09:31:31 -0700
Received: from tybalt.caltech.edu by venera.isi.edu (5.65c/5.61+local-22)
id ; Wed, 10 May 1995 09:30:00 -0700
Received: from alumni.caltech.edu by tybalt.caltech.edu with ESMTP
(8.6.7/DEI:4.41) id JAA27187; Wed, 10 May 1995 09:29:52 -0700
From:
Received: from mail06.mail.aol.com by alumni.caltech.edu with ESMTP
(8.6.4/DEI:4.41) id JAA15203; Wed, 10 May 1995 09:29:48 -0700
Received: by mail06.mail.aol.com
(1.37.109.11/16.2) id AA241733356; Wed, 10 May 1995 12:29:16 -0400
Date: Wed, 10 May 1995 12:29:16 -0400
Message-Id: <950510122914_113740492@aol.com>
To: rdv@alumni.caltech.edu
Subject: Re: REALISTIC DLT4000 perform...
*** EOOH ***
From:
Date: Wed, 10 May 1995 12:29:16 -0400
To: rdv@alumni.caltech.edu
Subject: Re: REALISTIC DLT4000 perform...
sorry it took me so long to reply.
we are currently getting over 2mb's sec sustained on the sgi platform with
some modifications to the firmware and inquiry strings.
drop me some mail in about a week and I will let you know how the tests
turned out.
jim
inline corporation
800 465 4637
1,,
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id ; Mon, 22 May 1995 10:48:51 -0700
Received: from tybalt.caltech.edu by venera.isi.edu (5.65c/5.61+local-22)
id ; Mon, 22 May 1995 10:48:49 -0700
Received: from alumni.caltech.edu by tybalt.caltech.edu with ESMTP
(8.6.7/DEI:4.41) id KAA06884; Mon, 22 May 1995 10:48:47 -0700
Received: from localhost by alumni.caltech.edu
(8.6.4/DEI:4.41) id KAA04842; Mon, 22 May 1995 10:48:42 -0700
From: rdv@alumni.caltech.edu (Rodney D. Van Meter)
Date: Mon, 22 May 1995 10:48:42 -0700
Message-Id: <199505221748.KAA04842@alumni.caltech.edu>
To: rdv@alumni.caltech.edu
*** EOOH ***
From: rdv@alumni.caltech.edu (Rodney D. Van Meter)
Date: Mon, 22 May 1995 10:48:42 -0700
To: rdv@alumni.caltech.edu
Path: nntp-server.caltech.edu!news.cerf.net!newsserver.sdsc.edu!news.tc.cornell.edu!news.cac.psu.edu!news.pop.psu.edu!hudson.lm.com!godot.cc.duq.edu!newsfeed.pitt.edu!gatech!news.sprintlink.net!worf.qntm.com!root
From: Ralf-Peter Rohbeck
Newsgroups: comp.arch.storage
Subject: Re: DLT2000 on HP887
Date: 19 May 1995 19:02:57 GMT
Organization: Quantum GmbH
Lines: 429
Message-ID: <3piq11$2ji@worf.qntm.com>
References: <1995May15.161808.22423@dsi.bc.ca>
NNTP-Posting-Host: worf.qntm.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 1.1N (Macintosh; I; 68K)
To: wtw@dsi.bc.ca
X-URL: news:1995May15.161808.22423@dsi.bc.ca
wtw@dsi.bc.ca (William Wong) wrote:
>* I read form the FAQ that there is a DLT FAQ, could somebody tell me
>where can I find it?
Here we go. It resides on a machine inside qntm.com, and it hasn't been
maintained for a while.
+------------------------------------------------------------------------+
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@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. @ 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 to
be about 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.
=========================================================================
Ralf-Peter Rohbeck rrohbeck@qntm.com
Quantum GmbH-Application Engineering-Central Europe (+49) 69-950767-18
Berner Str. 28, 60437 Frankfurt, Germany fax (+49) 69-950767-91
1,,
Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17)
id ; Mon, 22 May 1995 10:48:56 -0700
Received: from tybalt.caltech.edu by venera.isi.edu (5.65c/5.61+local-22)
id ; Mon, 22 May 1995 10:48:55 -0700
Received: from alumni.caltech.edu by tybalt.caltech.edu with ESMTP
(8.6.7/DEI:4.41) id KAA06889; Mon, 22 May 1995 10:48:54 -0700
Received: from localhost by alumni.caltech.edu
(8.6.4/DEI:4.41) id KAA04846; Mon, 22 May 1995 10:48:50 -0700
From: rdv@alumni.caltech.edu (Rodney D. Van Meter)
Date: Mon, 22 May 1995 10:48:50 -0700
Message-Id: <199505221748.KAA04846@alumni.caltech.edu>
To: rdv@alumni.caltech.edu
*** EOOH ***
From: rdv@alumni.caltech.edu (Rodney D. Van Meter)
Date: Mon, 22 May 1995 10:48:50 -0700
To: rdv@alumni.caltech.edu
Path: nntp-server.caltech.edu!ferrari.mst6.lanl.gov!newshost.lanl.gov!ncar!gatech!news.sprintlink.net!worf.qntm.com!root
From: Ralf-Peter Rohbeck
Newsgroups: comp.arch.storage
Subject: Re: DLT2000 on HP887
Date: 19 May 1995 19:06:54 GMT
Organization: Quantum GmbH
Lines: 9
Message-ID: <3piq8e$2ji@worf.qntm.com>
References: <1995May15.161808.22423@dsi.bc.ca>
NNTP-Posting-Host: worf.qntm.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 1.1N (Macintosh; I; 68K)
X-URL: news:1995May15.161808.22423@dsi.bc.ca
P.S. Have a look at
http://www.quantum.com/support/bulletins/tape.html
=========================================================================
Ralf-Peter Rohbeck rrohbeck@qntm.com
Quantum GmbH-Application Engineering-Central Europe (+49) 69-950767-18
Berner Str. 28, 60437 Frankfurt, Germany fax (+49) 69-950767-91