Thank you, again, Trident. That was very helpful
I did run that command, and we have a number of tapes with 0.0 (probably some data but not enough to round it up to a whole number), 1.1, 1.2, etc., before hitting the ones with more substantial utilization. I have some more questions for corroboration.
All the nodes that write to this storage pool are in one of three collocation groups, and there are no nodes that are not assigned to one of those three. I verified that. We have never changed the "MAXSCRatch" setting for the pool, and it's currently far greater than the number of volumes in the pool.
If we have any tapes in this storage pool that are not in the tape library then should these be included in the number of volumes used or only the ones in the tape library ?
For a primary pool, all tapes should be in the library. Any reclaim/move cannot work on tapes that are not present. Only copy pools can be removed. The reclaim process for these will make new tapes based on primary pool, and then you can return the empty tapes to the library. This is the DRM part of SP.
For example, if there are 200 tapes in the pool, but 50 are stored outside the tape library (we do not use reclamation on this pool so some of the older full primary pool tapes are boxed in order to free up storage slots) then would you still set MAXSCRatch to 200 or only to 150 ?
Again, we can only work on the tapes that are present. But yes, set it to something less than 200. If these have a low filling rate, you can consolidate these by moving data. Either remove the collocation from from nodes, or reduce maxscr to a lower number.
2. So as we work our way through, if we always change MAXSCRatch first to match the number of volumes in the pool then TSM will not be able to load a scratch tape to move any data and will instead be forced to use only the existing filling volumes. Is that right ?
Yes. Collocation will always try to either write the nodedata to the smallest number of tapes. For a DR purpose, this is wise as restore of data will require fewer tape mounts.
In our case, we have plenty of filling tapes with nodes in each of the collocation groups, so we should be okay for a while as we progress.
3. Let's say we had 200 volumes in the pool, and the MAXSCRatch was set to 1000. If we change that to 200, and then run a "move data" on a volume, then once the move is completed, we would then have 199 volumes (1 volume now pending the reusedelay for the pool). If we ran another "move data" on another volume, without first decreasing the MAXSCRatch from 200 to 199, then TSM *could* load 1 scratch tape if it thought it needed one.
It may. Depends upon the enviroment. If your single task is to reduce number of tapes, set maxscr to 150 and start filling up existing volumes in filling state.
For the tapes with lowest util, issue move data, and you will read data from that tape and write it to a tape in filling state in the same pool.
So to be safe, every time before running "move data" we would need to first always decrement the MAXSCRatch by 1 (or whatever number was necessary to match the number of volumes used), and so on and so forth, just as long as we have enough filling tapes with nodes in each of the collocation groups to accommodate backups. Otherwise, failure to reduce the MAXSCRatch accordingly *could* result in more scratch tapes getting used during the move(s), null and voiding the benefit. That right
4. But even if MAXSCRatch was greater than the number of volumes in the pool, would TSM load a scratch tape for a "move data" if there was at least one filling tape (readwrite) with nodes in that collocation group ?
If you have 50 nodes and each node has less data than the capacity of a tape, only 50 tapes would be needed.
5. You mentioned the possible use a file class volume(s) and then migrate to tape later. What about using a disk volume ? Any preference ?
You can migrate from DISK->FILECLASS. Not sure if you are allowed to migrate from FILECLASS -> DISK. I know you can move data in that direction.