reclamation of virtual volumes

[yampam]

Hi all ,
Using TSM v5.4 , DRM using virtual volumes .
when I'm tring to run spcace reclamation to the remote storage pool its start a reclamation process ,in the actlog of the source server i have the messages :
ANR1163W Space reclamation started for volume NEWR.BFS.218635102, storage pool RS_COPYPOOL .
ANR1163W Offsite volume NEWR.BFS.218635102 still contains files which could not be moved
no mount accured , no progress of the schedule, just this massages (and a lot of them) .

Any help with this will be appreciated.
Thanks
Yam.

 

[n9hmg]

check volume status. If the virtual vaulting server was ever unreachable when your server asked for a volume, the volume will be in "unav" status. Even if the volumes it says it couldn't reclaim are all good, other volumes containing fragments of what's on those can cause reclamation to fail. That's the legitimate reason for a failure.

The other one is a bit of squirreliness in 5.4. Shortly after my implementation went steady-state, my server started calling back only the db tapes. By the time I was informed that we were "running out of tapes", I had many dozens of tapes offsite which were less than 1% used - many in "Empty" state. I started using "move data" to kick the process along and get some scratch coming back. I also manually recalled all the "Empty" tapes, and as soon as I put those to "read-write" status while checked in, they were removed from the storage pool. Once I got some breathing room, I called IBM. They acknowledged that there are unresolved issues with relcamation, and their only recommendation was to use "move data" on volumes with lots of reclaimable space. Gee, what a good idea!

Eventually I moved all the ..."stuck?"... data, and reclamation has run mostly fine from then on - 2 volumes that required "move data" to get that last object moved off.
I hope you don't have the issue with empty volumes not going away, since you can't check them in.