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:[EMAIL PROTECTED]]On Behalf Of
Jon Milliren
Sent: Wednesday, May 09, 2001 9:17 AM
To: [EMAIL PROTECTED]
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:[EMAIL PROTECTED]]On Behalf Of
> Jon Milliren
> Sent: Tuesday, May 08, 2001 10:21 AM
> To: [EMAIL PROTECTED]
> 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
>
> [EMAIL PROTECTED]
> (412) 624-2727 office
> (412) 292-2070 mobile
--
Jon Milliren
Systems Administrator
University of Pittsburgh
Office of Institutional Advancement
[EMAIL PROTECTED]
(412) 624-2727 office
(412) 292-2070 mobile
