ADSM-L

Re: [ADSM-L] removing copystg keeps data on copy volumes

2010-08-18 07:41:30
Subject: Re: [ADSM-L] removing copystg keeps data on copy volumes
From: Nick Laflamme <dplaflamme AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 18 Aug 2010 06:40:42 -0500
On Aug 18, 2010, at 5:57 AM, Richard Sims wrote:

> On Aug 18, 2010, at 5:54 AM, Mehdi Salehi wrote:
> 
>> Hi everyone,
>> stg1 has stg2 as copy pool and they are synced. If you set the copystg of
>> stg1 to null, why stg2 still has copy data of stg1? Why doesn't TSM
>> delete/expire the copy data?
> 
> Because it should not, according to the architecture.
> The role of a copy storage pool is to retain a copy of data as long as that 
> data is in the primary pool from which it was copied.

I don't think Richard meant what he wrote. (Boy, is that a scary sentence to 
write!)

A copy storage pool is not associated with a specific primary storage pool. If 
data in a copy storage pool is in ANY primary storage pool, it remains in the 
copy storage pool. It's been this way since day 1. 

Admittedly, this can make things difficult when you have a mix of storage that 
needs copy storage pools and storage that is self-replicating. "Difficult," in 
the sense that data keeps living in the copy storage pool even as the size of 
data in the non-replicated storage pool shrinks.  At that point, you either 
start a new copy storage pool so the older, larger one is obsolete, or you live 
with it until the non-replicated storage is retired. 

Nick
<Prev in Thread] Current Thread [Next in Thread>