ADSM-L

Re: MOVE NODEDATA on a copypool doesn't process anything

2003-06-01 09:46:41
Subject: Re: MOVE NODEDATA on a copypool doesn't process anything
From: Jurjen Oskam <jurjen AT QUADPRO.STUPENDOUS DOT ORG>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Sun, 1 Jun 2003 15:46:10 +0200
On Sun, Jun 01, 2003 at 02:33:22PM +0300, Zlatko Krastev/ACIT wrote:

> --> ... from storage pool COPY01 to storage pool COPY01 ...
>
> TSM is smart enough. Try using TOstgpool=<another copypool> parameter of
> MOVe NODEdata command.

This is not possible (emphasis mine):

TOstgpool
     Specifies the name of a storage pool to which data will be moved. This
     storage pool must be in the NATIVE or NONBLOCK data format. **This
     parameter is optional and does not apply when the source storage pool
     is a copy storage pool.** That is, if the source storage pool is a copy
     storage pool the destination must be the same copy storage pool. If a
     value is not specified, data is moved to other volumes within the
     source pool.
     Note:
          If you are moving data within the same storage pool, there must be
          volumes available that do not contain the node data you are
          moving. That is, the server cannot use volumes that contain the
          data to be moved as destination volumes.



If MOVE NODEDATA would work the same way as MOVE DATA does for an offsite
volume beloning to a copypool (i.e.: retrieve the files from an onsite
primary pool), this would provide for a very easy and cheap way to make
sure that certain filespaces are quickly restored in a DR scenario. By way
of the MOVE NODEDATA command, you would only need one or two volume mounts (in
a noncollocated copypool) instead of many more when restoring during DR.


Unfortunately, MOVE NODEDATA only works this way when the volumes that
contain the data to be moved are onsite and available. This make MOVE
NODEDATA almost useless in this scenario, since copypool volumes are
offsite for a reason. :-)



I opened a PMR with IBM support for this behaviour. Initially, I was told
that this 'works as designed'. However, MOVE NODEDATA does things
that are not right in my (very humble) opinion:

* MOVE NODEDATA reports success, even when a non-existant filespace was
  specified.

* If, for a random filespace, some copypool volumes are onsite and some
  are offsite, MOVE NODEDATA only moves the files in the filespace that
  are contained on the onsite part of the filespace. However, MOVE
  NODEDATA still reports success in this case, and no mention whatsoever
  is made that part of the filespace has not been moved at all (not even
  in the 'Failed files' counter of the summary). The only way you can tell
  is to check whether the summary of the MOVE NODEDATA reports a
  'Moved Files' number equal to the amount of files in the entire filespace.
  This gets difficult if you're moving entire nodes.


So I told this to IBM Support in response to their 'works as designed', and
above issues are still being checked out.


Thanks for your reply,
--
Jurjen Oskam

PGP Key available at http://www.stupendous.org/