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]