ADSM-L

Drivers for 3590's

1996-12-05 11:40:37
Subject: Drivers for 3590's
From: "BELL, CRAIG" <rcbell AT VNET.IBM DOT COM>
Date: Thu, 5 Dec 1996 08:40:37 PST
Ref:  Note from     "ADSM: Dist Stor Manager"  (attached)

>> I mostly lurk, but now have a question I would like an answer to from
>> IBM.
>>
>> We are looking at using 3590's with ADSM.  I have made note of many
>> comments to the effect that ADSM device drivers for the 3590 do not take
>> advantage of the hardware capabilities and that you, therefore, cannot
>> get anything near the "theoretical" speed with them.  Are there plans to
>> rewrite the 3590 drivers for ADSM to correct this?  Otherwise, it would
>> be like buying a Ferrari to drive to the grocery store when a Ford
>> Escort would do as well.
>>
>> TIA,
>>
>> Janet Curtis
>> udpjcc AT usi.utah DOT edu
>>
>> Center for High Performance Computing
>> University of Utah
>> Salt Lake City, Utah

First of all, I apologize for taking so long to respond the this append at the
I would like to address this, and I hope many people take note as this rumor
seems to be strong in certain shops.

This is NOT a driver issue at all, nor is it even the general case for ADSM.
The issue of concern here is that the 3590 tape is serpentine in its track
layout and this somehow impedes the device driver's ability to locate to a
given position.  This is not true.  When ADSM appends data to a tape, it uses
the 3590 high speed locate function provided by 3590 to go directly to the EOD
and begin writing.  The track layout is transparent to the application.
Likewise, any reading of that tape is positioned by the high speed locate.
So if you hear that ADSM is not using the capabilities of 3590, DON'T BELIEVE
IT!

So what are they talking about?

There are a few applications, mostly using the API client,  that are heavy on
the read/restore side of tape usage.  If the application is reading a number of
files from the tape, AND the files are small relative to the tape's capacity
(eg, 25MB), AND they are randomly spread over the tape, then each file must
still be located on the tape in the same order that they were written to the
tape (note: this is STILL high speed locate).  This means that if the first
file to be restored is at the Physical BOT, the second file may be on the same
track but at the physical EOT, and the third may be on another track but back
at the physical BOT.  With this scenario, the tape has to be forwarded all the
way to the end of tape to get the second file, then rewound again to get the
third.  The better solution is to get the first and third files which are both
near the BOT, THEN get the second.  This saves a rewind.  In a worse case
scenario, you could rewind several times.

There isn't an easy fix for this, but neither does it describe most customers'
applications and needs, especially for normal backup and archive work.  Nor
does it mean 3590 performance is bad!  An application that reads small file
data from a single cartridge in a RANDOM fashion, round the clock, and is
tryingto shave seconds off its total restore time might have cause for concern.
But total throughput on 3590s with ADSM is quite good and getting better with
current and future enhancements  (network speeds, client CPU, and server disk
speeds notwithstanding).  There are currently several options for tuning
performance.  Perhaps those with experience doing that could post some of their
results, along with some of the throughput rates they are getting on 3590s.

Craig Bell
ADSM Server Development
<Prev in Thread] Current Thread [Next in Thread>