ADSM-L

Re: migrate stg with duration set

2006-06-14 05:42:19
Subject: Re: migrate stg with duration set
From: Steven Bridge <ccaasub AT UCL.AC DOT UK>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 14 Jun 2006 10:41:44 +0100
>On Jun 13, 2006, at 12:29 PM, Steven Bridge wrote:
>
>> Has anyone used the duration setting with a 'migrate stg'
>> successfully ?
>> I was assuming the migration would be cancelled when specified
>> number of
>> minutes was up ( or shortly thereafter ). I am finding it makes no
>> difference
>> at all.
>
>We need substantive information about what you are seeing...
>
>The exhaustion of the time interval causes the TSM server to issue an
>internal cancel to the migration process; but, like any other cancel,
>that may not be immediate. At a minimum, the physical file currently
>being processed needs to complete its transfer. And if the source
>tape is undergoing read retries, or the target tape is undergoing
>retry operations due to write errors (which can be quite a while),
>that results in further delay.
>
>But what are you actually seeing when you perform Query PRocess?  Is
>the quantity of data moved continually increasing over time?  What
>final messages appear in the Activity Log when the process finally
>does conclude?  In particular, does the expected ANR4925W appear?  If
>not, I'd report to TSM Support.
>
>     Richard Sims

I was assuming I had misunderstood the command in some way. I'm a bit
surprised no-one else has noticed this. I tried it for the first time
last week :

tsm: TSM_O>q stg

Storage      Device       Estimated    Pct    Pct  High  Low  Next Stora-
Pool Name    Class Name    Capacity   Util   Migr   Mig  Mig  ge Pool
                                                    Pct  Pct
-----------  ----------  ----------  -----  -----  ----  ---  -----------
NOCOBUDK     DISK             658 G   88.9   88.9    95   90  PNOCOBUTP

tsm: TSM_O>migrate stg NOCOBUDK lo=10 dur=140
ANR2110I MIGRATE STGPOOL started as process 88.
ANR1000I Migration process 88 started for storage pool NOCOBUDK manually,
highMig=95, lowMig=10, duration=140.
ANS8003I Process number 88 started.

( Following morning over 12 hours later )

tsm: TSM_O>q proc
 Process Process Description  Status
  Number
-------- -------------------- -------------------------------------------------
      88 Migration            Disk Storage Pool NOCOBUDK, Moved Files: 1763708,
                               Moved Bytes: 317,265,149,952, Unreadable Files:
                               0, Unreadable Bytes: 0. Current Physical File
                               (bytes): 14,077,952 Current output volume:
                               L00093L3.

which I manually cancelled. Here are the pertinent actlog entries :

2006.06.06 18:33:29  ANR0984I Process 88 for MIGRATION started in the
                      BACKGROUND at 18:33:29. (SESSION: 19059, PROCESS: 88)
2006.06.06 18:33:29  ANR2110I MIGRATE STGPOOL started as process 88. (SESSION:
                      19059, PROCESS: 88)
2006.06.06 18:33:29  ANR1000I Migration process 88 started for storage pool
                      NOCOBUDK manually, highMig=95, lowMig=10, duration=140.
                      (SESSION: 19059, PROCESS: 88)
2006.06.07 10:06:09  ANR2017I Administrator ADMIN issued command: CANCEL
                      PROCESS 88  (SESSION: 19885)
2006.06.07 10:06:09  ANR0940I Cancel request accepted for process 88. (SESSION:
                      19885)
2006.06.07 10:06:10  ANR1020W Migration process 88 terminated for storage pool
                      NOCOBUDK - process canceled. (SESSION: 19059)
2006.06.07 10:06:10  ANR0986I Process 88 for MIGRATION running in the
                      BACKGROUND processed 1755506 items for a total of
                      316,201,046,016 bytes with a completion state of FAILURE
                      at 10:06:10. (SESSION: 19059)

I have tried it with smaller duration values this week and still no joy.
Looks like I'll have to report it to support.

+----------------------------------------------------------------------+
 Steven Bridge     Storage Section, Systems Group, Information Systems,
                        EISD,  University College London

<Prev in Thread] Current Thread [Next in Thread>