ADSM-L

Re: incomplete copy pool

1999-01-07 13:13:59
Subject: Re: incomplete copy pool
From: "Thomas A. La Porte" <tlaporte AT ANIM.DREAMWORKS DOT COM>
Date: Thu, 7 Jan 1999 10:13:59 -0800
You can issue the following query for the affected volume:

 'q con VOLNAME copied=no'

and that will give you a list of files for which no copy exists
in a copy storage pool. If the objects on the tape have been
properly copied to a copypool location, you should get zero hits
for the query.

Thomas A. La Porte
DreamWorks Feature Animation
tlaporte AT anim.dreamworks DOT com


On Fri, 8 Jan 1999, Leo Humar wrote:

>Hi ADSMers,
>
>My message on the 19/12/1998 didn't get any response regarding the integrety 
>of copypools when a primary volume is unavailable during the copy process and 
>made available again. ADSM ignores the volume that was unavailable when I 
>start another copy process. I understood that any interupted process would 
>continue and pickup the uncopied portion of the primary storage pool. The 
>volume was not copied as I observed the process wich finished immediatly 
>without any error messages. The amount of data on the tape would have taken at 
>least 10 minutes to copy.
>
>Is there a command to verify the complete copy of a primary storage pool 
>without going through a disaster recovery procedure ?
>I created a new copypool and copied the primary tape pool to the new copypool 
>to be sure. Comparing the capacity of the old copypool and the new copypool 
>don't match when I add the volumes reported capacitys. Could this may be due 
>to the compression on the tapedrives or are the figures in volumes not precise 
>? I have a Spectralogic tape library with two AIT drives and creating this new 
>copypool of 150GB took around 10 hours. We are not looking forward to have to 
>do this when we have all our clients connected with a capacity of around the 
>500 to 800GB.
>Did anybody else have this experience ?
>How can I consolidate the copypool ?
>
>Thanks you for any comments on this problem.
>I can avoid this problem by checking the volume status before a copy procedure 
>but this could be a nasty gotcha.
>
>
>Leo Humar
>LCS Pty Ltd
>lhumar AT vic.bigpond.net DOT au
>
<Prev in Thread] Current Thread [Next in Thread>