Dear Colleagues,
The following is a technical note related to the installation and
operation of DLT drives on UNIX machines. It is basically a summary
of the tests and experience I have had with our 20 Gigabyte DLT4000
machine.
In general it seems as though the DLT4000 behaves well as a
stand-alone SCSI device. On both the RS6000 and my Intel laptop
running LINUX the drive was easily installed. On the RS6000 using
SMIT we simply defined the drive as an "other SCSI tape" after it was
plugged in. On my LINUX machine with a SCSI PCMCIA card it was enough
to simply plug it in and it was recognized as a SCSI tape DLT drive.
- From my reading on the net it seems that on some other machines there
is slightly more involved. If you need information on how to install
these drives on another machine you should refer to the WWW pages at
Quantum where there are a set of installation notes(see references at
end of this message).
After installation you should insure that the drive you have is is
operating properly. More specifically, you want to make sure that it
is running as fast as the design parameters. Basically there are two
things that you need to do to insure that you get maximum throughput:
You must use a large block size. You should use a block size of at
least 10Kbytes. When you are using program like tar you should
manually set the block-size to 64K(you can do this with the -b
option). Our MACRO data tapes are written with a block size of 21600.
This block size seems large enough to obtain maximum throughput.
When you are using the dd command(which is used to copy raw data files
from tape to disk or vice-a-versa) you must be careful in what
parameters you use. Here is an example of how to copy a file from a
MACRO data tape to a disk:
dd if=/dev/rmt0.1 of=run010706.zeb bs=21600
It is *very* important that you specify "bs" and not "ibs". "ibs"
stands for "input block size" while "bs" stands for "block size". The
dd command allows you to separately specify the input and output block
size(this is sometimes necessary). If you only specify the input
block size dd will use the default output block size(512 bytes in this
case since we are writing to a disk). If the two block sizes are
different dd will do the internal blocking necessary to convert two
block sizes to each-other.
If instead you use "bs" you are specifying that both the input and
output block sizes are the same. Because of this dd will do nothing
but pass the data. Then the disk itself will do the necessary
blocking in hardware. This makes a huge performance difference.
Although I never noticed it before this actually is noticeable even
with exabyte drives.
The second thing you need to do is to use attach a local disk to the
same SCSI interface as your tape drive. If you try to read or write
the tapes over the network not only will you be limited by your
network speed, the tape drive may run even more slowly since your
drive will go out of streaming mode and will be constantly starting
and stopping.
One useful trick to determine if you are getting close to you maximum
throughput onto your disk drive is to compare with the time it takes
to read from the tape without writing onto a disk at all. You can do
this by using /dev/null. The following command will time reading some
MACRO data off of a tape without writing the output anywhere:
time dd if=/dev/rmt1 of=/dev/null bs=21600
When things are running at full speed you should get transfer speeds
of about 1.3-1.5 Mbytes/sec. In addition if you listen to the drive
it will almost always be running.
You can increase this speed if you choose to use compression. The
amount of compression you get will depend on the type of data you are
writing. With text data you might see factors of 2 in compression.
However, our MACRO data compresses only by about 30%. In addition, I
am not sure about the compatibility of algorithms between drives(they
are stored on EPROMS) or how stable these algorithms will be in the
future. So, for long term storage of things like raw data I would
recommend against using compression. However, for backups and shorter
term storage of tapes you will use with your own drive compression
might be very useful.
Of course if you do use compression there is no way to know exactly
how much data you wrote. One trick to measure the compression factor
is to write both compressed and non-compressed data to a tape and
measure the amount of time it takes to read them back. Assuming you
are only limited by the tape itself(use the /dev/null trick) the
relative times should tell you the compression factor between the two
cases.
I noticed no speed difference between using 10 Gbyte and 20 Gbyte
tapes. Refer to Doug's earlier note for information about tape
prices.
One interesting thing I found in my research is that although it seems
we are buying these drives from lots of companies in fact the DLT
technology seems no different than exabyte. It looks to me as if
digital makes all of it.
For further information you can consult the following sources:
The FAQ for comp.arch.storage has some DLT information. There is a copy at:
http://alumni.caltech.edu/~rdv/comp-arch-storage/FAQ-1.html
There is a DLT FAQ which was written by someone at Quantum at:
http://alumni.caltech.edu/~rdv/comp-arch-storage/dlt-faq.html
There are technical bulletins on attaching DLTs to several
machines(RS6000,HP,SUN) at Quantum:
http://www.quantum.com/support/bulletins/tape.html
- -Chris Walter
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMQMnQhuXA8lNmiGNAQHBHwQAsWURDtFBV1wuE7cgSATWOb4uGNHZDl/S
JYzEAhc3hZvC23cdigiTzLuFMet8XtHywCGnrqooiWmnmlaesFjqRST3HfKNTj8X
p5NH9f6FaGH6gVZV1Se8xxBdfzHt10vMe3yNiJkmOpyrCLRCkmJRsenJur1qF7Is
B7gcq6P19VU=
=bAue
-----END PGP SIGNATURE-----