Well... ok, when migration starts, adsm gathers lists of "stuff" to migrate
number of migration tasks is set by
1) migpr
2) # drives
3) # of unique node's data in a stgpool

(it will be the least of the above)

I believe ADSM in being more memory kind has reduced the size of the initial
list of "stuff" to migrate per task and when it finishes with one list of
"stuff" (task/migration process) it then checks the high/low values against
current conditions to see if it should gather another list of "stuff" and
continue with a new migration process...

I use admin schedules to start migration when I want and then reset High/Low
values about 1 hour before I want it to really be out of the system (so
basically I'm allowing 1 hour for running migration tasks to end)  I could
see where a quick reset back to the higher values wouldn't totally clear the
pool.

I wouldn't excatly call it premature termination... more like the tasks at
hand complete and the conditions to initiate a new one don't exist anymore
(and this is because individual tasks seem to build smaller lists to
process.....)

Dwight

> ----------
> From:         Scott Fluegge[SMTP:sfluegge AT VENATORGROUP DOT COM]
> Reply To:     ADSM: Dist Stor Manager
> Sent:         Tuesday, January 04, 2000 11:36 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Disk Storage Migration Issue
>
> Hello all...
>
> I have just discovered that Migration no longer worked the way it used to.
> Once
> upon a time I was able to set the storage pools high and low values to 0,
> migration would start, then after maybe 20 seconds I would reset the
> values to
> 90 and 70.  Migration would continue to run until it reached the pre-set
> value
> of 0, not 70.  Now when I run it, if I reset the values before it
> finishes, the
> process assumes the new values and will end prematurely!
>
> Have others found this to be true?  Is this by design or accident?  And
> lastly,
> how do I automate the migration process if I need to watch it complete
> before I
> can update the values?
>
> Thanks for you input...
>
> Scott
>