Ref: Your note of Thu, 5 Dec 1996 18:44:23 -0500 (attached)
From: Richard Sims <rbs AT BU DOT EDU>
Subject: Re: Drivers for 3590's
Comments: cc: rbs AT acs.bu DOT edu
To: Multiple recipients of list ADSM-L <ADSM-L AT VM.MARIST DOT EDU>
Richard Sims, Boston University Office of Information Technology writes
> Craig - Thanks for your elaboration. It's great to be getting more
> information on this.
> Could you clarify the issue of ADSM storing the location of the file
> on the tape? Is it stored in the database along with the other
> information about the file? When was this capability introduced?
> The July HONE item as written says that the capability was not there
> then, and in searching the latest lpp.README file for the server I
> don't see an enhancement PTF for this. I am also curious about the
> status of the HONE item is: its optimal-solution item (number 3)
> specifies that the server is to keep information about file location
> in its database and that the server would optimally perform
> retrieval, which it seems you are saying has now been implemented.
> But just when was that? This is obviously a point of confusion.
Again, I'm sorry that this is so late for you in coming, especially
because throught this dialogue, I'm seeing that I haven't made a
clear differentiation between two separate issues. The first issue
is, does ADSM use high speed locate to get to a logical block, and
does the serpentine wraps have anything to do with that. The answer
is, yes we do use it and the wraps are of no consequence. Implied is
that each file to be restored can be located to directly from its
logical block number that is indeed stored in our database and always
has been. I'm sorry that this is not the physical location (relative
to BOT) that is required to create an optimal retrieval order. That
information is not a published by the drives and not available to
ADSM. You're right in saying that this is the point of confusion.
But what I wanted to address is the fear I see in (sometimes
potential) customers that a high speed locate doesn't exist, or that
serpentine wraps somehow keeps adsm from locating to any given block
quickly.
> As you can appreciate, this issue has been aggravated by IBM being
> unwilling to provide the kind of information that would allow
> customers to understand what is going on. All this should be
> published in the ADSM manuals. Without that, customers are left to
> grasp what little information comes from any source, and that
> information has consistently said that there were deficiencies in
> ADSM's handling of 3590 technology. And given what we were seeing
> from data retrieval operations, there was good reason to believe it.
> Certainly you can appreciate that when customers spend hundreds of
> thousands of dollars and see poor performance from their equipment
> they want to know what is wrong. We as a customer went to IBM about
> this and were told that there were 3590 handling problems, as
> referenced by the HONE item. All this for lack of published
> information.
I agree that there is a communication problem on this, the source of
which is partly misunderstanding what needed to be documented. As I
point out, the logical block doesn't need documentation, it's only
used by adsm. What is needed is a published interface to the physical
location, and that is not provided by the hardware, either 3590 or
DLT (which also uses serpentine wraps). Without that interface, any
application such as ADSM has no way to optimize the retrieval order.
> The July quote which you reference:
>
> > 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.
>
> was from another customer who found ADSM's performance such that he
> embarked upon experimentation to see if he could do better, such that
> he wrote his own manager to the 3590 tape driver, and thereby
> achieved improved performance. Yes, optimal access to files on tape
> can be done: the essential question was whether ADSM would do it.
> And on that point we had only corroborating evidence that there was a
> problem.
The one big problem this and any other customer wanting to do this has,
is that once the data is written, it is possible (especially with the API
client) to analyze the supposed position of files on the tape to
optimize retrieval. In Dr. Michael Fink's append yesterday, he gave
out the ftp reference to the paper "On the Modeling and Performance
Characteristics of a Serpentine Tape Drive". They were dealing with DLT,
but a key point of the paper is that they had to after-the-fact figure
out where the segments, or blocks, were layed out before they could
optimize. I know I beating a dead horse, but my point is that that
information is not yet available to the application.
> Please look back at your original posting this morning. It
> asserts correctly that appending to a 3590 tape is an efficient
> positioning and writing operation. We all get excellent throughput
> in that area. Everyone expects that from any tape; it's a non-issue.
> But then your posting seems to go on to denigrate the complementary
> "read/restore side of tape usage" almost as though writing tapes is
> the norm and that reading them is an anomaly which entails inevitable
> loss of performance. You said that "reading of that tape is
> positioned by the high speed locate" but made no mention until your
> reply later today as to whether ADSM knew of position so as to
> optimize access. As you pointed out, high speed or not, doing that
> over many files (as in a mass restore) is very time-consuming unless
> the agent controlling it can make the most of current position.
> Please take a fresh look at it the same way that we customers first
> saw it.
I think that the point I made was lost in what locate information we
were talking about. I only meant to assert that we can do high speed
locate to individual files. The bigger issue is optimizing the
retrieval of a collection of randomly placed files (from a single tape).
This is where adsm is not able to optimize, again because that information
is not (yet?) a published interface.
Also related is the sparseness of those files. The more sequential the
restore, the less physical location matters. Random and sparsely placed
files would benefit most from optimizing the restore order with physical
location, and this is what I mean to say that it does not fit every
customer profile. But I won't argue that some customers would benefit
from this.
> So all of this points to an obvious need for definitive,
> published information so that customers can know what to expect for
> performance from their ADSM+3590 combination, and thereby have a
> basis for measurement so as to perceive when a performance problem
> lies in some other area. It makes no sense to blame the customer for
> not having the information which the vendor has not provided. We as
> customers are ourselves trying to provide responsive systems to the
> people we serve, and prove that we have invested large sums of
> (their) money wisely. In short, we need solid information.
Agreed. We do have a lot of performance information for adsm+3590, but
its focus is on streaming throughput and sequential restore.
(Laurence Holley has made performace related appends to this forum.)
More work in the area of random, sparse retrievals may be warranted,
if and when it can be supported.
> Your submission today was the first piece of information in the
> long history of this issue which began to address it. It's a great
> starting point: let's see it followed up in published documentation.
> As an example of the further information that would help here: We
> know from the 3590 device drivers manual that it is STIOCSETPOS which
> performs "high speed locate"; but that's all it says. There is no
> perspective as to serpentine positioning or time realities in getting
> to any given place on a 3590 tape. And then there is the larger
> point about ADSM knowing about the position of the file on the tape:
> what it stores, and how it uses it to position for optimal retrieval
> times. We would like to see that published - and have it show up in
> a query command, which would help those who might like to optimize
> access to individual files in a batched operation...and say whether
> or not ADSM itself might optimize access when given a list of files
> vs. being asked to perform a filespace restoral.
I think you are probably referring to the physical location which is
not available to adsm. If this were externalized by the drive's micro
code (both 3590 and Quantum/DLT) we could possibly use it.
> 3590s are great
> technology: they would benefit from almost a whole chapter in an ADSM
> manual describing the advantages and implications of their use in an
> ADSM environment. And how about all the parameters which you allude
> to which would enhance their performance? You have
> information-starved customers out there - let's get that information
> out.
Your comments are noted. ADSM developers and performance testers have
made that information available informally through appends, SHARE and
Guide presentations, etc, but book or chapter is certainly worth
considering.
> Thanks for the information you are providing. We need your
> assistance to make our installations perform as we need them to and
> as IBM would like to ensure satisfied customers.
Your welcome, and thanks for your comments as well!
> Richard Sims, Boston University Office of Information
> Technology
|
