ADSM-L

Re: LTO restore performance - seek problem?

2001-05-04 13:50:17
Subject: Re: LTO restore performance - seek problem?
From: "France, Don G (Pace)" <don.france-eds AT EDS DOT COM>
Date: Fri, 4 May 2001 13:50:57 -0400
TSM Level 2 responded to John, he forwarded their response...

IBM located a microcode problem, they developed a patch, a customer is
already testing the fix.



 -----Original Message-----
From:   Bern Ruelas [mailto:bern AT CADENCE DOT COM] 
Sent:   Friday, May 04, 2001 9:49 AM
To:     ADSM-L AT VM.MARIST DOT EDU
Subject:        Re: LTO restore performance - seek problem?

John,

This problem is very interesting to me as we are thinking of throwing away
our
17 ATL libraries running Legato's NetWorker 6.0.1 in favor of 2 LTO 3584's 
running
Tivoli Storage Manager (we will actually use a Sun E420). I thought
colocation
was suppose to speed up recoveries, it sounds as if it's not working as 
advertized....

-Bern
At 02:47 PM 5/4/2001 +0200, Karsten Hüttmann wrote:
At 02:47 PM 5/4/2001 +0200, Karsten Hüttmann wrote:
>Content-Type: text/plain; charset=iso-8859-1
>X-MIME-Autoconverted: from 8bit to quoted-printable by mailserver.carus.de 
>id OAA14706
>
>Hi!
>Your problem sounds familiar to me.
>We've similar problems running HSM (or now: Tivoli Space Manager) with
>a LTO 3583. (Ok, it is not the best way to use a LTO Library with
>HSM, but that was not my decision). For a recall of 2 GBs we need half a
>day.
>But: a normal restore of a client is as fast as we expected.
>
>John Schneider wrote:
>
> > 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: jdschn AT attglobal DOT net * Phone: 
> > 636-492-0247
> > * Lowery Systems, Inc.
> > * 1329 Horan                  Disclaimer: Opinions expressed here are
> > * Fenton, MO 63026                   mine and mine alone.
> > ***********************************************************************
>
>--
>Mit freundlichen Grüssen / with regards
>Karsten Hüttmann
>
>Content-Type: text/x-vcard; charset=us-ascii;
>  name="Karsten.Huettmann.vcf"
>Content-Description: Card for Karsten H|ttmann
>Content-Disposition: attachment;
>  filename="Karsten.Huettmann.vcf"
>X-MIME-Autoconverted: from 8bit to quoted-printable by mailserver.carus.de 
>id OAA14706