I think you can raise the thresholds right after the migration begins as
the single process will move all the data for the largest node before
checking the thresholds again. 


Kelly J. Lipp
VP Manufacturing & CTO
STORServer, Inc.
485-B Elkton Drive
Colorado Springs, CO 80907
719-266-8777
lipp AT storserver DOT com

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Sims
Sent: Tuesday, June 19, 2007 10:33 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Moving one nodes date from primary direct access
disk

On Jun 19, 2007, at 11:20 AM, Andrew Carlson wrote:

> I would like to move about 6TB of data for a node from Random Access 
> disk to sequential accesss.  Since move nodedata doesn't work on 
> random access pools, I was wondering if there is an easy way to do it.

> The data is archive data, and the only plan I could come up with was 
> moving data from individual volumes to a staging area, a sequential 
> access pool, then moving nodedata from there to the final destination 
> sequential access pool.  Anyone have any better ideas?  Thanks for any

> input.

Andy -

I would expect that amount of data to represent the largest quantity in
the disk storage pool.  If that is the case, then allowing the data to
migrate down to a node-collocated sequential pool, with
MIGPRocess=1 in effect and migration levels lowered, would cause that
dominant node's data to be handled first.  You could then do Query
PRocess periodically to estimate when the data is just about all moved,
and then be ready to cancel the process and reset the migration levels
once all the node's data is moved.  With the destination being a tape
pool, the node transition would be apparent, as a partially filled tape
would be left as the single process then went on to mount a fresh tape
for the next node.  In any case, any "overshoot" would be on a separate
tape, whereupon you could Move Data that node's data back to the disk
stgpool, or wherever.

   Richard Sims