ADSM-L

Re: reclaim spoy stgpool volumes

2001-05-09 19:56:06
Subject: Re: reclaim spoy stgpool volumes
From: Joe Faracchio <brother AT SOCRATES.BERKELEY DOT EDU>
Date: Wed, 9 May 2001 16:56:54 -0700
SORRY!

 I now see the discussion is about offsite=COPYPOOLs
and my previous note was about TAPEPOOLS.  I never have any
offsite tapes go offsite while in FILLING.  They only go on
Wednesdays and only if they're FULL!

AND probably the part about what number you set reclamation to
and how it chooses FULL doesn't  apply since the algorythms for
offsite appear to be different from onsite pools.
... joe.f

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
>
<Prev in Thread] Current Thread [Next in Thread>