There's a third way - you can use reclaim.  This is similar to move data,
with reconstruct=yes, but is more automated.   Just set reclaimstg to your
new storage pool, and reclaim down to 1.  You may have to do a few move
datas at the end, to get the tapes that are 0% reclaimable.

At 08:05 AM 6/26/2002 -0400, Remeta, Mark wrote:
>Actually you can reconstruct the aggregates during a move data. I forget
>what version it started with but there is a command line option for move
>data called Reconstruct=yes that will reconstruct the aggregates during a
>move data....
>
>Mark
>
>
>-----Original Message-----
>From: Zlatko Krastev/ACIT [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, June 25, 2002 7:26 AM
>To: [EMAIL PROTECTED]
>Subject: Re: Adding a second library
>
>
>Stephen,
>
>you already found the *best* answer yourself - yes, set new stgpool as
>next to existing one and lower migration thresholds to 0. Just some
>additional remarks:
>- set the "old" pool(s) as read-only and (optional) set maxscratch=0. This
>would prevent nodes to fill the pool while you are trying to drain it to
>the next one - might be endless :)
>- later when you have time (even it is immediately) change all the
>references to "old" pool(s).
>Yes, this would also reclaim the tapes but will also recreate the
>aggregates. The latter would not be performed if you use 'move data'! And
>you should perform "moves" for each tape while migration is automatic
>server-driven process.
>I hope this sets the line straight.
>
>Zlatko Krastev
>IT Consultant
>
>
>
>
>Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
>Sent by:        "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
>To:     [EMAIL PROTECTED]
>cc:
>
>Subject:        Adding a second library
>
>I've added a second 7337 library to our ADSM system (15 DLT robot with 2
>drives). I've got the system seeing the library, and I have a new
>devclass defined with the new library.
>
>What I would like to do is have two of our stgpools (AFS_TAPE_POOL and
>COPYPOOL) we have defined use this new library, with the others staying
>in the original library. I can't change the devclass on a stgpool with
>the update stgpool command, so I'd have to create a new stgpool.
>
>What's the best way to get the data in the old stgpool out of that pool
>into the new pool? Should I just set NEXTpool to point to the new pool
>and set the migration level to 0%? Then when all the data is moved out
>of the original pool delete the pool? (This would give the added benefit
>of reclaiming all wasted tape space at the same time....)
>
>Steve Cochran
>Dartmouth College
>
>Confidentiality Note: The information transmitted is intended only for the
>person or entity to whom or which it is addressed and may contain
>confidential and/or privileged material. Any review, retransmission,
>dissemination or other use of this information by persons or entities other
>than the intended recipient is prohibited. If you receive this in error,
>please delete this material immediately.


--
Paul Zarnowski                         Ph: 607-255-4757
747 Rhodes Hall, Cornell University    Fx: 607-255-8521
Ithaca, NY 14853-3801                  Em: [EMAIL PROTECTED]

Reply via email to