ADSM-L

Drivers for 3590's

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

Richard Sims, Boston University Office of Information Technology writes:

>  I obtained a copy of the HONE item, and it does describe ADSM failing to
>  account for the serpentine technology of the 3590, corroborating what
>  David Bohm said.  Specifically, when ADSM goes to access files on the
>  tape it processes the tape sequentially, not knowing that by switching
>  tracks it could access the files much faster, in a more random manner.
>  The crux of the problem is that ADSM records file location information
>  only to the point of knowing what tape the file is on.  The optimal
>  solution, as outlined in the HONE item, is to additionally track where
>  each file is on the tape, in the ADSM database.

I still disagree with the allegation, and Dave was not specifically addressing
your situation.  The append he was responding to contained the following:

> I did find that the 3590 is a great performer as far as tape devices go.
> When talking directly to tape, I was able to randomly retrieve 100KB files
> off a 10GB tape with reasonable performance.  If I was careful how I sorted
> files before reading them, I could achieve consistently good performance.

This describes what I re-iterated in my previous append.  Your 46 hour restore
could not be accounted for by this, and I would have expected to have opened a
PMR for this.

We DO know where the file is on the tape, not just what tape, and we DO use
high-speed locate to locate the file.  Again, the WORSE case scenario for not
accounting for the serpentine half-wraps is to retrieve 8 files, each at one
end of a half-wrap (aka track) and that you could rewind the tape up to 7
times, at about 2 minutes a rewind.  (Any other files in between these the
worst-placed files are picked up on the way and so the rewind time does not
grow with the number of files.)  I do not believe that this accounts for your
46 hour experience, which can be explained in other terms.  For instance, an
append was just put out on this forum regarding lost VCR data- that alone would
account for such a long restore but other things could also (such as writing to
8mm!).  Earlier levels of ADSM V2.1 did not have a "lost VCR" warning messages.
My experience is that just reading all the data off an entire tape should take
much less time than that.

Craig Bell
<Prev in Thread] Current Thread [Next in Thread>