I ran into this exact problem when I had one 1GB random access DISK based
primary storage pool (about 27% used). I didn't backup it up to it's own
copy storage pool, but I did back it up to the same copy storage pool
where I copied the other management classes. When reclamation occurred, I
would often have one or two offsite tapes that were 0% full, 99%
reclaimable, and the reclaim job ran all day with one output, and no input
volumes mounted.
To fix the immediate needs, I would find a nice non-stormy day and update
reclamation=100, cancel existing reclamation, go offsite, retrieve the
offending tapes, insert them to the library, update them to readonly, and
move the data manually. Those moves went fairly quickly... lightning
compared to the reclamation.
To fix the long term needs, when I had time to do it, I created a new
device class type of DIR_FILE with an estimated capacity of 10MB, then
created a new sequential access storage pool using that DIR_FILE device
class that allowed up to 100 volumes (approx 1GB total), then pointed the
DIRMC to use that new storage pool. Then I moved the data from the random
disk volumes to the new storage pool (so it filled up just over 27 volumes
right away).
After all that, the reclamation is going at a better rate. I think it is
because the one 1GB disk volume containing all of the directory objects
was just too resource intensive to scan. The 10MB volumes are much faster
to scan through. Personally, it doesn't make sense that a random access
volume would have that much trouble finding the file, but I had read other
posts with problems similar to mine, so I made those changes.
Hope this helps
Todd
Debi Randolph <Debra.Randolph AT FBOL DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
08/05/2003 12:44 PM
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Fax to:
Subject: Re: Reclamation of Copy Dirs
Yes, it's forever and 2 days with no tape drive contention.
We're using 3590E1A's, but moving to LTO in the next 30 to 60 days.
I only have 12 volumes utilized in the Copy Dirs pool. So we've turned
over the specific volumes a number of times. So I don't think it's any
one volume that could be causing the problem, as far as read/write errors
go.
How does reclamation on this pool work? When you reclaim Copy Dirs, it
only uses one tape drive, just an output volume, no input volume. All
the
other storage pools use two drives, an input volume and an output volume.
So is it going back to the client to re-write the data to a new tape?
Thanks,
Deb Randolph
Richard Sims
<rbs AT BU DOT EDU> To: ADSM-L AT VM.MARIST
DOT EDU
Sent by: "ADSM: cc:
Dist Stor Subject: Re: Reclaimation
of Copy Dirs
Manager"
<[email protected]
.EDU>
08/05/2003 11:17
AM
Please respond to
"ADSM: Dist Stor
Manager"
>Is it supposed to take forever and 2 days to reclaim my Copy Dirs pool?
Not for the price of the product...
You haven't told us if you are checking for tape drive contention,
as in drives busy with higher priority tasks.
If no contention, you may have some "difficult" tapes, consuming costly
retries in reading or writing. To try to isolate the problem, you can
do Move Data on indicative tapes and follow the progress, watching for
particular points where things crawl, and go from there, as in examining
I/O load or paging on your server.
We also don't know your tape technology type: as you may have seen from
historic posting, start-stop on some drives is painful.
Richard Sims, BU
******************* N O T I C E *******************
The information contained in this e-mail, and in any accompanying
documents, may constitute confidential and/or legally privileged
information. The information is intended only for use by the
designated recipient. If you are not the intended recipient (or
responsible for the delivery of the message to the intended
recipient), you are hereby notified that any dissemination,
distribution, copying, or other use of, or taking of any action in
reliance on this e-mail is strictly prohibited. If you have received
this e-mail communication in error, please notify the sender
immediately and delete the message from your system.
***************************************************
******************* N O T I C E *******************
The information contained in this e-mail, and in any accompanying
documents, may constitute confidential and/or legally privileged
information. The information is intended only for use by the
designated recipient. If you are not the intended recipient (or
responsible for the delivery of the message to the intended
recipient), you are hereby notified that any dissemination,
distribution, copying, or other use of, or taking of any action in
reliance on this e-mail is strictly prohibited. If you have received
this e-mail communication in error, please notify the sender
immediately and delete the message from your system.
***************************************************
|
