ADSM-L

Re: reclaim spoy stgpool volumes

2001-05-09 19:52:36
Subject: Re: reclaim spoy stgpool volumes
From: Joe Faracchio <brother AT SOCRATES.BERKELEY DOT EDU>
Date: Wed, 9 May 2001 16:53:24 -0700
I find the opposite with my system at 3.7.2.
FILLING tapes are candidates for reclamation.

Maybe its the way I do it.  I don't set the reclamation
to a number far below the first candidate. I use perl.

When I have a few tapes with 22% reclaim and that's the lowest
(or highest, read: first candidates)  I set the tapepool rec to
22 it WILL reclaim the FULL tapes first.  BUT if I keep it at 22
it will continue with the FILLING.

... joe.f.

P.S my perl program uses something like this select tool I use:
 ($1 is how 'deep' I want to go)

select volume_name,pct_reclaim,status,pct_utilized -
from volumes where stgpool_name='TAPEPOOL' -
and pct_reclaim>$1 -
order by pct_reclaim desc

Joseph A Faracchio,  Systems Programmer, UC Berkeley
Private mail on any topic should be directed to :
   joef AT socrates.berkeley DOT edu

On Wed, 9 May 2001, Lindsay Morris wrote:

> The "filling" tapes are not candidates for reclamation - TSM still hasn't
> written all the way to the end of the tape yet.  Only the FULL tapes might
> be reclaimed, and the smallest one is 55.7% full, which means "upd stg xxx
> recl=44" should cause it to be reclaimed.
>
> It's normal to have all your tapes about 50% used. If you try to reclaim a
> tape that is mostly full, reclamation will probably require a new scratch
> tape, so even though it frees up THIS tape, you still have no net gain in
> scratch tapes.
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Jon Milliren
> Sent: Wednesday, May 09, 2001 9:17 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: reclaim spoy stgpool volumes
>
>
> Hi all,
>
> Lindsay Morris wrote:
> >
> > does "q vol stg=copypool" show you any volumes with a "pct util" less than
> > 60%?
>
>         Here you go... Question, how does Pct Utilization come into play
> with
> respect to reclaim? I usually go by the "Pct Reclaimable Space" in the
> web gui. Could this be where I'm making my mistake? I use the web gui
> for checking storage pools, volumes, etc, and the cli for issuing
> command and viewing the actlog and client events. Anyhow, you can see
> that 3 volumes are under 60% utilized, 2 of which were in my offsite
> locate (vols 0001 to 0008). The remaining volumes are in the library. I
> do a nightly copy stg for both of my primary pools (disk and tape).
>
> adsm> q vol stg=copypool
>
> Volume Name               Storage      Device      Estimated    Pct
> Volume
>                           Pool Name    Class Name   Capacity   Util
> Status
>                                                         (MB)
> ------------------------  -----------  ----------  ---------  -----
> --------
> DLT00001                  COPYPOOL     AUTOCLASS    36,063.2   55.7
> Full
> DLT00002                  COPYPOOL     AUTOCLASS    35,677.2   64.4
> Full
> DLT00003                  COPYPOOL     AUTOCLASS    49,671.5   68.6
> Full
> DLT00004                  COPYPOOL     AUTOCLASS    73,638.1   73.8
> Full
> DLT00005                  COPYPOOL     AUTOCLASS    58,195.2   96.1
> Full
> DLT00006                  COPYPOOL     AUTOCLASS    47,009.5   60.5
> Full
> DLT00007                  COPYPOOL     AUTOCLASS    20,660.3  100.0
> Full
> DLT00008                  COPYPOOL     AUTOCLASS    41,500.5   52.2
> Filling
> DLT00010                  COPYPOOL     AUTOCLASS    89,129.7   31.8
> Filling
> DLT00011                  COPYPOOL     AUTOCLASS    36,274.1   93.1
> Filling
> DLT00015                  COPYPOOL     AUTOCLASS    20,480.0    6.1
> Filling
> DLT00016                  COPYPOOL     AUTOCLASS    78,390.8   67.3
> Full
>
>
>
> > try "q actlog begind=-3 s=recla" and see if reclamation even tried to
> start.
>
>         Ok, here is that...
> adsm> q actlog begind=-3 search=recla
>
> Date/Time
> Message
> --------------------
> ----------------------------------------------------------
> 05/08/01   09:16:31  ANR2017I Administrator MJON issued command: QUERY
> ACTLOG
>
> search=RECLA
> 05/08/01   09:16:55  ANR2017I Administrator MJON issued command: QUERY
> ACTLOG
>
> seatch=RECLAMATION
> 05/08/01   09:17:14  ANR2017I Administrator MJON issued command: QUERY
> ACTLOG
>
> search=RECLAMATION
> 05/08/01   09:17:49  ANR2017I Administrator MJON issued command: QUERY
> ACTLOG
>                       begind=-10
> search=RECLAMATION
> 05/08/01   09:20:30  ANR2017I Administrator MJON issued command: UPDATE
> STGPOOL
>                       COPYPOOL DESCRIPTION="Copy storage pool for
> DR"
>                       ACCESS=READWRITE COLLOCATE=NO RECLAIM=60
> MAXSCRATCH=250
>
> REUSEDELAY=2
> 05/08/01   10:01:46  ANR2017I Administrator MJON issued command: UPDATE
> STGPOOL
>                       COPYPOOL DESCRIPTION="Copy storage pool for
> DR"
>                       ACCESS=READWRITE COLLOCATE=NO RECLAIM=40
> MAXSCRATCH=250
>
> REUSEDELAY=2
> 05/09/01   08:30:57  ANR2017I Administrator MJON issued command: QUERY
> ACTLOG
>                       begind=-3
> search=recla
>
>         I've been checking a lot. You can also see where I've tried setting
> the
> reclaim threshold to 60 and 40. Anyhow, reclaim hasn't started despite
> my desperate flailing =).
>
> > If it did, do a second "q actlog" and look at all the messages right after
> > that time - maybe they explain why it turned off.
> >
> > Then send us "q stg copypool f=d".
>
>         Here you go...
>
> adsm> q stg copypool f=d
>
>                Storage Pool Name: COPYPOOL
>                Storage Pool Type: Copy
>                Device Class Name: AUTOCLASS
>          Estimated Capacity (MB): 12,222,706.7
>                         Pct Util: 3.1
>                         Pct Migr:
>                      Pct Logical: 98.2
>                     High Mig Pct:
>                      Low Mig Pct:
>                  Migration Delay:
>               Migration Continue:
>              Migration Processes:
>                Next Storage Pool:
>             Reclaim Storage Pool:
>           Maximum Size Threshold:
>                           Access: Read/Write
>                      Description: Copy storage pool for DR
>                Overflow Location:
>            Cache Migrated Files?:
>                       Collocate?: No
>            Reclamation Threshold: 40
>  Maximum Scratch Volumes Allowed: 250
>    Delay Period for Volume Reuse: 2 Day(s)
>           Migration in Progress?:
>             Amount Migrated (MB):
> Elapsed Migration Time (seconds):
>         Reclamation in Progress?: No
>  Volume Being Migrated/Reclaimed:
>   Last Update by (administrator): MJON
>            Last Update Date/Time: 05/08/01   10:01:46
>
>         Hope this sparks an idea. To me, everything looks like it should. I
> must be missing something obvious.
>
> Jon
>
>
> > -----Original Message-----
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf 
> > Of
> > Jon Milliren
> > Sent: Tuesday, May 08, 2001 10:21 AM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: reclaim spoy stgpool volumes
> >
> > Lindsay Morris wrote:
> > >
> > > The quote Jack offered is relevant to PRIMARY pools, but not to COPY
> > pools,
> > > I think.
> > >
> > > TSM reclaims COPY (off-site) storage pools by using the drives and tapes
> > > available to the PRIMARY (on-site) storage pool.
> >
> >         Right, that's what I gleaned from the admin guide.
> >
> > > Jon, surely your onsite pool has two or more drives, right?
> > > Maybe reclamation didn't start because it's a relatively low-priority
> > > process (look up "preempt" in the Admin guide), and something more
> > important
> > > (like backup db) was running.
> >
> >         Right again. My primary storage pool has two drives, in fact, I
> see
> > reclaim going on for that storage pool.
> >
> >         I left my copy storage pool reclaim threshold value at 40 over the
> > weekend. No reclaim took place for my copy pool, and I still have
> > volumes with > 40% reclaimable space.
> >
> >         The Admin guide says reclamation threshold is "The percentage of
> > reclaimable space that a sequential access media volume must have before
> > the server can reclaim the volume." I have the reclamation threshold
> > parameter for the copy pool set to 40, so I should expect volumes with >
> > 40% recaimable space to be reclaimed, right?
> >
> >         Is there anything else that could prevent reclaim from occurring?
> As
> > far as I can tell, I've set it up properly.
> >
> >         Big thank you to everyone who responded!
> >
> > Jon
> >
> > --
> > Jon Milliren
> > Systems Administrator
> > University of Pittsburgh
> > Office of Institutional Advancement
> >
> > jon.milliren AT ia.pitt DOT edu
> > (412) 624-2727 office
> > (412) 292-2070 mobile
>
> --
> Jon Milliren
> Systems Administrator
> University of Pittsburgh
> Office of Institutional Advancement
>
> jon.milliren AT ia.pitt DOT edu
> (412) 624-2727 office
> (412) 292-2070 mobile
>