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
>
|