Please don't confuse migration with reclamation! Migration is how data
gets INTO the tape storage pool; reclamation is how nearly-empty tapes
coma back OUT OF the tape storage pool. Over the long term, you cannot
control the rate of migration, except by controlling what goes on at the
client nodes. You've got to migrate whatever they back up, no matter how
much of it there is, or else your disk storage pools will fill up.
Eventually it expires, and our job is to get those tapes back - which is
a process we have a lot of control over. Our ONLY WAY of influencing the
fullness of the tape storage pools is through the expiration and
reclamation processes.
The main issue here is that reclamation is not occuring. This was
happening here at UIC when I was abruptly assigned to tame an
out-of-control ADSM system. The same thing was happening - the previous
person thought that the problem was that the reclamation threshold was
not set low enough - when the real problem was that it was not set HIGH
enough. The manual says to never set it below 50 or else you will get no
benefit - it will be unable to combine two tapes onto one.
It's confusing, but the number on the RECLAIM= parameter is the
percentage EMPTY for selecting tapes to reclaim, not the percentage full.
So, at 10%, you are trying to reclaim tapes that are already nearly full.
This cannot produce the large number of scratch tapes that you are
desperate for.
RIGHT NOW, you should set your RECLAIM= numer to 95% and leave it there
all day, until it stops reclaiming. (Took us a week.) Then lower it to
90% and reclaim some more. During these steps you will be mounting a
large number of tapes in a short period of time - but the good news is
that they will all become scratch tapes. By starting at 95%, you get the
most scratch tapes, for the least effort, in the shortest period of time
and you are desparate for free scratch tapes right now.
You can tell how you are doing by piping the output from QUERY VOLUME *
into any stat package (I use SPSS) and printing a simple frequency table.
Keep lowering your RECLAIM= number a few points at a time, until you
reach an equilibrium. On our system that is 75%, but YMMV. I can tell
we're doing well, because the number of tapes more than 75% empty is only
a small handful, and we free about the same number of tapes through
reclamation as we consume through migration.
The suggestion of different RECLAIM= numbers over the course of a day is
OK, but will only help a little. Consider the life of a tape. It starts
out full, or 0% empty. Over time, files on it become expired one at a
time, and its emptiness gradually rises to meet the RECLAIM= number you
have set. If it is set at 75%, for instance, you will probably find that
you are reclaiming mostly 76% empty tapes. A few will be more empty than
that, but not many. If you are reclaiming a lot of tapes that are more
empty than your RECLAIM= setting, consider a higher setting. This is part
of finding your system's equilibrium. It's a Zen thing - pipe Q VOLUME
into your stat package every day, and stare at the numbers for a month -
and you will know when you've got the thing balanced right, because it
will just feel right. Then you can begin to see the meaningful trends -
such as how much of the growth in the number of tapes is real growth,
caused by more client nodes, and growth of existing client nodes.
Migration is not directly involved in the problem you are having. You are
probably migrating OK, as long as your disk storage pools are not filling
up and preventing client node backups from occuring.
However, you should consider NOT doing that daily full database backup,
and instead do a weekly full and daily incrementals. Why? It takes a lot
longer for a full backup, which takes up your drives for a longer period
of time, when they could be used doing reclamation instead. This will
consume exactly six (6) extra tapes, but I bet you can reclaim a lot more
than that in the time you gain by doing incrementals 6 days a week.
Andy's suggestion to look at backup policies for how long to keep deleted
and inactive files is good - that could make a bunch of tapes
reclaim-able instantly.
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
Aliases: u52983 AT uicvm.uic DOT edu R.Deschner AT uic
DOT edu
>From: "Sutton, Andy" <asutton AT SMMI DOT COM>
>Is the 10% your HighMig% Threshold or the LowMig% Threshold? Either
>way it seems too low, causing reclamation to spend more time on a daily
>basis freeing up space. I have my tape library set at 80%/60%
>respectively and get good results from reclamation. I also run daily
>backups of several AIX & NT systems and it's a constant battle to
>manage the space as fast as the data changes. You might also look at
>your backup policies. Particularly the parameters dealing with how long
>to keep inactive and deleted files.
>
>-----Original Message-----
>From: Naveed Mustafa [mailto:Naveed_Mustafa AT MCKINSEY DOT COM]
>Sent: Friday, April 10, 1998 8:17 AM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: scratch volumes in STK 9710
>
>
>Hi all,
>
>We have reached the maximum capacity of our STK 9710 library. Currently
>all our tape storage pools have the reclaimation threshold set to 10 and
>since we perform full ADSM database backup daily, the REUSEDELAY has bee
>set to 0. But these changes are not producing as much SCRATCH tapes as
>expected.
>
>Any other suggestion on how to further free up more slots in the library
>
>We are running ADSM V2.1.0.13 on an AIX machine.
>
>Thanks,
>Naveed.
>
>------------------------------
|
