Re: NEXTSTGPOOL with MAXSIZE does not work with MOVE DATA

I see nobody else has jumped into this, so I will.

I think IBM Support is right. MOVE DATA and Reclamation are
fundamentally different from Migration and Client Backup. They're
potentially going in the opposite direction - either sideways in the
Storage Heirarchy, or downwards - whereas Migration and Client Backup
are both going upwards.

The manual for MOVE DATA says:

STGpool
     Specifies the primary storage pool to which you want to move files
(the target storage pool). This parameter is optional and applies only
to moving data from primary storage pool volumes. If you do not specify
a value for this parameter, files are moved to other volumes within the
same storage pool.

This is quite clear. The target storage pool is THE storage pool it will
move the files to. It does not say that it will move it to that point in
the Storage Heirarchy, including anywhere uphill it has to due to
MAXSIZE, but it says to THAT pool. If the file doesn't fit due to
MAXSIZE, then the operation should fail.

This does leave you with how to solve your problem. I think doing MOVE
DATA to the Disk Storage Pool is about the best way. That way, you are
getting things into the Storage Heirarchy in the way intended, letting
Migration sort the files out by size, efficiently filling volumes higher
up in the heirarchy. This was the basic philosophy driving the original
design of the system, and it's at this basic design philosophy level
that I have to agree with IBM Support on this point.

Throw some extra temporary disk space at that Disk storage pool and make
it huge. Or perhaps define a separate temporary disk storage pool just
for this project, to reduce the performance penalty for your regular
backups. It could be a FILE disk storage pool, using all your favorite
RAID tricks to benefit large sequential files such as RAID0 Striping,
and it would fly, both on the way in and the way back out.

Who knows - you could be collocating. That could make a real mess of
this.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
======I have not lost my mind -- it is backed up on tape somewhere.=====


On Mon, 31 Jan 2005, Rushforth, Tim wrote:

>We have a Storage Pool hierarchy something like:
>
>
>
>DISK Stgpool (noliimt) --> File Stgpool (2GB limit) --> Tape Stgpool
>(nolimit)
>
>
>
>Clients backup to DISK, files smaller than 2GB migrate to "File"
>stgpool, everything else migrates to Tape.
>
>
>
>We've changed the MAXSIZE to 2GB and wanted to move all files from Tape
>that are smaller than 2GB to the File Stgpool.  This can be done by
>moving everything to DISK and let migration handle it.
>
>
>
>I thought it would be more efficient to just move this data to the File
>stgpool but ran into the following error:
>
>ANR1150W Move data process terminated for volume VOLNAME -
>      unable to move file to target storage pool due to
>      exclusion by size.
>
>
>
>
>
>So I thought it was weird that Migration will honor the Nextstgpool when
>a maxsize is set but MOVE DATA does not.
>
>
>
>(Also client backups/archives will honor the nextstgpool).
>
>
>
>Along with MOVE DATA, MOVE NODEDATA and RECLAMATION also do not work in
>this scenario.
>
>
>
>I called Tivoli Support and they said working as designed and are going
>to update the documentation to state this.
>
>
>
>My questions are:
>
>
>
>-          does anyone else think this is working a bit weird (ie.
>Migration and client sessions work fine when writing to a stgpool with a
>maxsize and nextstgpool but move data, move nodedata and reclamation do
>not).
>
>-          Any other (efficient) way of doing what I want - move the
>small files from tape to the file pool
>
>
>
>Thanks,
>
>
>
>Tim Rushforth
>
>City of Winnipeg
>