Hello,
the LTO microcode that is supposed to fix a performance
problem with the LOCATE function as I explained below
is known as "PGA3".
It is still not yet available. Last I heard was that it could
be available early next week, date subject to change
of course.
I will let you know when I have more information.
Regards,
-----------------------------------------------------------------
Rejean Larivee / IBM
TSM/ADSM Level 2 Support
----- Forwarded by Rejean Larivee/Quebec/IBM on 05/08/01 06:24 PM -----
Rejean
Larivee/Quebec To: [EMAIL PROTECTED]
/IBM@IBMCA cc:
Sent by: Subject: Re: LTO restore performance -
seek problem?
"ADSM: Dist
Stor Manager"
<[EMAIL PROTECTED]
IST.EDU>
05/03/01 01:18
PM
Please respond
to "ADSM: Dist
Stor Manager"
Hello John,
I have worked with one customer getting the same
behaviour on restore, even with the 0C1 microcode
applied. Small bursts of files being restored at a time.
We have captured TSM and Atape traces and found
TSM to be waiting for LOCATE commands to complete.
We found this to be an LTO microcode problem.
A new microcode has been developed and is currently
going through final stages of testing.
>From my last conversation with the hardware engineers
involved, our customer should get this new microcode
early next week.
I will update the list as soon as our customer gets
the microcode installed and has a chance to test it.
I will also let you know what the "official" microcode
number is once I have it.
Regards,
-----------------------------------------------------------------
Rejean Larivee / IBM
TSM/ADSM Level 2 Support
John Schneider
<jdschn@attglo To: [EMAIL PROTECTED]
bal.net> cc:
Sent by: Subject: LTO restore
performance - seek problem?
"ADSM: Dist
Stor Manager"
<[EMAIL PROTECTED]
IST.EDU>
05/03/01 10:40
AM
Please respond
to jdschn
Greetings,
I have seen many posts on adsm.org about LTO, but none that
addresses the problem I am seeing. Backup speed seems to be fine, at
least as far as I can tell. But when I do a restore, I see a strange
behavior. The restore seems to happen in bursts, where the restore
pulls back files lickety-split for a awhile, then stops for 15-20
minutes, then continues. I think that the wait is the seek from one
spot on the tape to another. We have two tape drives in the IBM 3583
library, and the problem seems to be happening on both of them. We
upgraded to the 0CE1 version of the LTO microcode, but it has not
improved things that I can tell.
We restored 1.5 GB from our RS/6000 TSM server to a NT client, and
it took 47762 seconds, or 13 hours. All the data was on one tape, so it
is not a colocation problem. How long should it take an LTO drive to
seek? I have done these sort of restores on DLT, and it can usually get
from any place to any place on a tape within a few minutes. I expected
LTO to be at least as good. A 13 hour restore is completely
unacceptable.
Any input or things to try would be appreciated. By the way, the
TSM server is an RS/6000 F50 running AIX 4.3.3 ML4, with TSM 4.1.2. It
is running atape 6.0.4, and atldd 4.1.5.0, which are both the latest, I
believe. The NT client was TSM 4.1.2. Both are on the same switch on a
100MB Ethernet network, so I don't think the network is related in any
way.
TIA,
John Schneider
***********************************************************************
* John D. Schneider Email: [EMAIL PROTECTED] * Phone: 636-492-0247
* Lowery Systems, Inc.
* 1329 Horan Disclaimer: Opinions expressed here are
* Fenton, MO 63026 mine and mine alone.
***********************************************************************
