ADSM-L

Re: Slow Reclamation - And a need for speed...

2002-06-14 14:12:49
Subject: Re: Slow Reclamation - And a need for speed...
From: Bill Boyer <bill.boyer AT VERIZON DOT NET>
Date: Fri, 14 Jun 2002 14:10:58 -0400
Make sure that none of the 'primary' pool for the data on the offsite
volumes are in a DISK storage pool. Especially the target of the DIRMC
mgmtclass and then copying this data into the offsite pool with the rest of
the data. This is a 'feature', 'working as designed' in the reclamation
processes that if the primary copy of the data is on a DISK random-access
storage pool, then the file(s) are processed 1 at a time and each file is a
transaction. None of the MOVEBATCHSIZE stuff for this process... Do you
maybe have CACHE=YES for the disk storage pool(s)? Even though the data has
been migrated to onsite tape pool, the most primary copy of the data still
could reside in the disk storage pool. For the whole MOVEBATSIZE-stuff to
work, the primary copy needs to be on a sequetial storage pool.

Also, what are you using to control the offsite volume movement? Offsite
volumes won't go back to SCRATCH until you update their access from OFFSITE.
Until then they stay PENDING.

Another misconception is that setting the RECLAMMATION threshold back high
does not actually stop the currently running reclamation process. For onsite
pools, when the current reclamation task ends, no new reclamation tasks
should start back up, especially if you put it back to 100%. For offsite,
since the reclamation task is doing all volumes that were identified when
the process started, it will run to completion...whenever that is. If you
want to actually stop reclamation, set the RECLAIM= back to 100% ( of just
higher than any volumes' reclamation %) and then cancel the process.

Bill Boyer
DSS, Inc.