ADSM-L

Re: Slow Reclamation from disk

2002-06-26 12:01:41
Subject: Re: Slow Reclamation from disk
From: David Longo <David.Longo AT HEALTH-FIRST DOT ORG>
Date: Wed, 26 Jun 2002 11:59:42 -0400
This was from an old email of mine.  We got info that my last paragraph
was a good guess, it is a TSM design problem.  Notice carefully if when
the Reclamation is running slow, that there is just an output tape
and no input tape.  This means it is getting input files from disk and not
tape, if you are going tape to tape it should be fast like mine.

Also LTO tapes tend to exaggerate this problem due to "backhitching"
when writing small files or something like that.  That's why I noticed
it more on LTO than 3575 library.

There apparently isn't a fix planned by TSM, takes a lot of recoding
and redesign as I understand it.


David B. Longo
System Administrator
Health First, Inc.
3300 Fiske Blvd.
Rockledge, FL 32955-4305
PH      321.434.5536
Pager  321.634.8230
Fax:    321.434.5525
david.longo AT health-first DOT org


>>> ebrodeur AT SERTI DOT COM 06/26/02 09:54AM >>>
I am suddenly having the same problem...

Reclamation is very slow.  I barely manage to reclaim 1 GB/hour, which 
wasn't the case in the beginning (I think after all in the beginning I 
didn't have so much data outside).  I update the stg to reclaim=60.  I 
have a diskpool on a SAN (FastT500) and an LTO 3583 (also SAN attached 
through a San data GW).  My server is on AIX 5 (TSM 4.2.1.9).

Is there any reason why this should take forever like this?

Thanks for the help.

Etienne Brodeur





Daniel Sparrman <daniel.sparrman AT EXIST DOT SE>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
03/11/2002 11:25 AM
Please respond to "ADSM: Dist Stor Manager"
 
        To:     ADSM-L AT VM.MARIST DOT EDU 
        cc: 
        Subject:        Re: Slow Reclamation from disk


Hi

How is your diskpool configured? Is it placed locally on the machine, or 
is
it SAN attached?

Best Regards

Daniel Sparrman
-----------------------------------
Daniel Sparrman
Daniel Sparrman
Exist i Stockholm AB
Bergkällavägen 31D
192 79 SOLLENTUNA
Växel: 08 - 754 98 00
Mobil: 070 - 399 27 51


  
                      David Longo   
                      <David.Longo@HEALTH        To: ADSM-L AT VM.MARIST DOT 
EDU  
 
                      -FIRST.ORG>                cc:    
                      Sent by: "ADSM:            Subject:  Slow 
Reclamation from disk 
                      Dist Stor Manager"   
                      <[email protected]   
                      DU>   
  
  
                      2002-03-11 17:23   
                      Please respond to   
                      "ADSM: Dist Stor   
                      Manager"   
  
  





I have old TSM server 3.7.4.0 on AIX 4.3.3 with 3575-L32 library with
C-XL drives.  New server is TSM 4.2.1.9 on AIX 4.3.3 ML09 and
IBM 3584-L32 library with 8 FC-AL drives.

Having the 3584 running for about 6 weeks now, I see what some of
the talk about slownes in the last year actually is.  On BOTH TSM
systems there is slowness in offsite tape reclamation WHEN some
of the files being reclaimed are still on the Disk stgpool.

When tape reclamation starts, it figures out which tapes to reclaim and
where the data is - understand.  Then when it actually starts it
will copy files that are STILL in disk stgpool first before files that
are only on tape - makes sense.  Then move to files that are only on
tape.  However, when it is copying files from disk it is MUCH slower
than when copying from tape - I would say 10 times slower.

But when doing a MIGRATION disk to tape or BACKUP STGPOOL
fromdisk to tape on either system, it's like going from idle to 4th gear!
This slownes can happen on  thses system when there is NO OTHER
ACTIVITY but this single reclamation.

Having two different systems to compare at the same time seems
to indicate that this is NOT a disk problem or a tape problem (except
that the 3584 may not handle it quite as well).  Also our old system
tended to have disk pool emptier when reclaimation started and this
wasn't really noticed on that system until  I started paying close
attention.

I again point out that my 3584 really smokes when doing everything
else BUT reclamation from disk to tape.  So does the 3575 - relatively
speaking.

(My 3584 library is library F/W 2360 and drives are 18N2 as delivered,
I don't think this is problem but included for completeness).

It seems that this is some inherent Tivoli design flaw/feature in the
RECLAMATION process.  Anyone with detail  knowledge of
Reclamation can provide some insite?  Andy Raibeck?

Thanks,


David B. Longo
System Administrator
Health First, Inc.
3300 Fiske Blvd.
Rockledge, FL 32955-4305
PH      321.434.5536
Pager  321.634.8230
Fax:    321.434.5525
david.longo AT health-first DOT org 



"MMS <health-first.org>" made the following
 annotations on 03/11/02 11:37:16
------------------------------------------------------------------------------
---
This message is for the named person's use only.  It may contain
This message is for the named person's use only.  It may contain
confidential, proprietary, or legally privileged information.  No
confidentiality or privilege is waived or lost by any mistransmission.  If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it, and notify
the sender.  You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the
intended recipient.  Health First reserves the right to monitor all e-mail
communications through its networks.  Any views or opinions expressed in
this message are solely those of the individual sender, except (1) where
the message states such views or opinions are on behalf of a particular
entity;  and (2) the sender is authorized by the entity to give such views
or opinions.

==============================================================================


"MMS <health-first.org>" made the following
 annotations on 06/26/2002 12:00:54 PM
------------------------------------------------------------------------------
This message is for the named person's use only.  It may contain confidential, 
proprietary, or legally privileged information.  No confidentiality or 
privilege is waived or lost by any mistransmission.  If you receive this 
message in error, please immediately delete it and all copies of it from your 
system, destroy any hard copies of it, and notify the sender.  You must not, 
directly or indirectly, use, disclose, distribute, print, or copy any part of 
this message if you are not the intended recipient.  Health First reserves the 
right to monitor all e-mail communications through its networks.  Any views or 
opinions expressed in this message are solely those of the individual sender, 
except (1) where the message states such views or opinions are on behalf of a 
particular entity;  and (2) the sender is authorized by the entity to give such 
views or opinions.
This message is for the named person's use only.  It may contain confidential, 
proprietary, or legally privileged information.  No confidentiality or 
privilege is waived or lost by any mistransmission.  If you receive this 
message in error, please immediately delete it and all copies of it from your 
system, destroy any hard copies of it, and notify the sender.  You must not, 
directly or indirectly, use, disclose, distribute, print, or copy any part of 
this message if you are not the intended recipient.  Health First reserves the 
right to monitor all e-mail communications through its networks.  Any views or 
opinions expressed in this message are solely those of the individual sender, 
except (1) where the message states such views or opinions are on behalf of a 
particular entity;  and (2) the sender is authorized by the entity to give such 
views or opinions.

 ===========================================================================
<Prev in Thread] Current Thread [Next in Thread>