Richard Renshaw
07/23/97 11:45 AM
Well, the consensus seems to be that I'm getting about as good of
performance as I can expect from this configuration.
Steve Walling:
>We had similar performance issues with our TZ88 DLT drive (single 20/40
>gig tape). We are using the UNIX CPIO command and learned from another
>DU SA that blocking is an important issue with this setup. We use the
>following command: find /opt /db01 -depth -print | cpio -o -c -C65536
>-O/dev/rmt0h .
>The -C option specifies the block size, 64K, which is the maximum
>allowed. Our throughput was improved 2 fold by adding the -C option to
>our command. I hope that your method allows for specifying the block
>size so that my suggestion may help. Also, the 2:1 compression is
>marketing speak, true compression depends on the type of files being
>written.
Since I was already blocking at 64K using the -b 64 option of dump blocking
wasn't my problem.
J.James(Jim)Belonis II:
>Sounds like a nice fast DISK speed to me. Do you really expect the tape
>to write faster than the disk reads ?
>Using Digital's version of dump ? Or something like Legato Networker
>that backs up multiple disks simultaneously ?
>If only one disk at a time is being read, then you can't expect to run
into
>the DLT 7000's I/O limits since you are limited by disk access speed
>and throughput.
We are using Digital's version of dump and aren't looking to buy new backup
software to increase performance unless it will support our database
program (Ingres, and an old version) which nothing does.
alan_at_nabeth.cxo.dec.com:
>In the case of the system using the KZPAA, a big part of the problem
>is that a lot of the DLT 7000 performance comes from using Wide16
>transfers and the KZPAA doesn't support Wide. The one on the KZPSA
>is a bit harder. Since a device claiming to be a DLT7000 isn't
>the same as a TZ89, any customizations particular to the TZ89
>won't be used. You might need something explicit in cam_data.c
>(pre-V4) or /etc/ddr.dbase (V4) to enable something, such as a
>write cache.
I know the KZPAA should be slower, but what surprised me is we get almost
the same performance on either controller. I still haven't looked into
specifying anything explicit in /etc/ddr.dbase yet.
And the original question:
>Is anyone else having performance problems with DLT 7000 tapes.
>We have a 2 drive/10 tape jukebox from Overland Data that emulates an
>Exabyte 210 8mm library. The drives are recognized as DLT 7000 tapes and
>we can backup and restore find, but the performance we get is less than
>expected. The DLT 7000 is rated at 5 Meg/sec raw and 8-10 Meg/sec
>compress, yet in compressed mode the best we get is 3 Meg/sec. I know we
>are not getting the 2:1 compression either, since our 35Gig raw/70Gig
>compressed tapes fill up at about 60Gig, but that's not enough to drop the
>performance below the raw rating. We are running the drives from a pair
of
>2100 systems, here are their stats:
system 1 system 2
system 2100A 4/200 2100 4/275
memory 256 Meg 640 Meg
OS Digital UNIX 4.0b Digital UNIX 4.0b
controller KZPAA KZPSA
The DLT 7000 uses a differential SCSI connection, so system 1 runs thorugh
a single-ended to differential converter before attaching to the drive. So
here is what the wiring of the two systems looks like: (connector types in
parantheses)
system 1 KZPAA (SE SCSI-2)--(SE SCSI-1) converter (DiffSCSI-1)--(Diff
SCSI-3) DLT 7000
system 2 KZPSA (Diff SCSI-3)--(Diff SCSI-3) DLT 7000
Both drives are the only devices on their particular SCSI chain. I am
basing the transfer timings on system dumps that we run from cron on
weekends so there isn't much else of a system load at the time. The
systems are both database servers, and I shut down the database for the
backups.
Any ideas would be appreciated, and I will summarize if I ever figure this
out....
Thanks in advance,
Rick Renshaw
Received on Wed Jul 23 1997 - 18:02:45 NZST