ADSM-L

Re: [ADSM-L] Does Move Data recover space on virtual volumes?

2011-03-11 00:56:32
Subject: Re: [ADSM-L] Does Move Data recover space on virtual volumes?
From: Erwann SIMON <erwann.simon AT FREE DOT FR>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 11 Mar 2011 06:55:03 +0100
Hi All,

My advice is to read closely this Joerg's message that gives all the answers !

Main points are :
- 1 virtual volume on the source server equals 1 archive object on the target server - when a virtual volume returns to scratch on the source server, then begins the deletion grace period for the associated archive object on the target

Best regards / Cordialement / مع تحياتي
Erwann SIMON


Le 10/03/2011 22:33, Joerg Pohlmann a écrit :
Keith, make sure you run reclamation on the virtual volume-based storage pool 
on your source server. By default, there is a deletion grace period of 5 days 
before the virtual volume (actually the archive object) is deleted on the 
target server. Oncce it is deleted at the target server you need to make sure 
the archive object is deletd on the storage pool by running inventory 
expiration. Inventory expiration creates reclaimable space in the tape storage 
pool that holds these archive objects and you can now run reclamation to get 
the physical tape space back.

Move data on a virtual volume on the source server will have the same effect as 
reclamation. Move data on a physical tape at the target server has the same 
effect as reclamation. But, why do all this manually as opposed to just letting 
reclamation run on a daily basis.

Regards,

Joerg Pohlmann

----- Original Message -----
From: Keith Arbogast<warbogas AT INDIANA DOT EDU>
Date: Thursday, March 10, 2011 3:48 pm
Subject: Re: [ADSM-L] Does Move Data recover space on virtual volumes?
To: ADSM-L AT VM.MARIST DOT EDU

My specific problem is with a tape pool that is a target for
virtual volumes created by a remote TSM server. The number of
cartridges in use by the pool goes up and up, at a faster rate
than the data growth on the remote server. I suspect there are
many virtual volumes in the target pool with not many active
files left on them.

My understanding is that even one active file in a virtual
volume keeps all the space used by it on a tape from being
reclaimed. So far, my only resort seems to be to do MOVE DATA on
virtual volumes with log pct_utilization, using
'reconstruct=yes'. That won't be efficient or fast.

If I am missing something, please let me know.

My thanks to all who have offered suggestions so far,
Keith