Use the UPDATE STGPOOL command to change any parameters in an existing storage pool.
You can use this command to modify selected parameters for the specified storage pool. If you do not explicitly update a parameter, it remains unchanged.
The UPDATE STGPOOL command takes three forms, depending on whether the update is for a primary storage pool assigned to random access devices, a primary storage pool assigned to sequential access devices, or a copy storage pool. The syntax and parameters for each form are defined separately.
Privilege Class
To issue this command, you must have system privilege, unrestricted storage privilege, or restricted storage privilege for the storage pool to be updated.
Syntax for Updating a Random Access Storage Pool
(1)
>>-UPDate STGpool-------poolname-------------------------------->
>---+------------------------------+---------------------------->
'-DESCription--=--description--'
>---+-----------------------------+----------------------------->
'-ACCess--=--+-READWrite---+--'
+-READOnly----+
'-UNAVailable-'
>---+------------------------------+---------------------------->
'-MAXSIze--=--+-maxfilesize-+--'
'-NOLimit-----'
>---+---------------------------+------------------------------->
'-NEXTstgpool--=--poolname--'
>---+---------------------------+--+-------------------------+-->
'-HIghmig--=--highmigvalue--' '-LOwmig--=--lowmigvalue--'
>---+--------------------+--+------------------------------+---><
'-CAChe--=--+-Yes-+--' '-MIGPRocess--=--numprocesses--'
'-No--'
1 | You must specify at least one optional parameter on this command. |
Parameters for Updating a Random Access Storage Pool
No new writes are permitted to the volumes in the storage pool from other volumes outside the storage pool. However, system processes (like reclamation) are permitted to move files within the volumes in the storage pool.
If this storage pool has been specified as a subordinate storage pool (with the NEXTSTGPOOL parameter) and is defined as readonly, the storage pool is skipped when system processes (like migration) attempt to write files to the storage pool from volumes in another storage pool.
No new writes are permitted to the volumes in the storage pool from other volumes outside the storage pool. However, system processes (like reclamation) are permitted to move files within the volumes in the storage pool. Files can also be moved or copied from this storage pool to another storage pool.
If this storage pool has been specified as a subordinate storage pool (with the NEXTSTGPOOL parameter) and is defined as unavailable, the storage pool is skipped when system processes (like migration) attempt to write files to the storage pool.
To limit the maximum physical file size, specify an integer (1 to 999999) followed by a scale factor. Scale factors and their meanings are:
For example, MAXSIZE=5G specifies that the maximum file size for this storage pool is 5 gigabytes.
If a file exceeds the maximum size and no pool is specified as the NEXTSTGPOOL, the file is not stored. If a file exceeds the maximum size and a pool is specified as the NEXTSTGPOOL, the file is stored in the next storage pool that can accept the file size. If you specify the NEXTSTGPOOL parameter, at least one storage pool in the hierarchy should have a MAXSIZE value of NOLIMIT. By setting MAXSIZE to NOLIMIT for at least one pool, you ensure that no matter what its size, a file can be stored somewhere.
To remove an existing storage pool from the storage hierarchy, specify a null string ("") for this value.
You cannot create a chain of storage pools that leads to an endless loop through the NEXTSTGPOOL parameter. At least one storage pool in the hierarchy must have no value specified for NEXTSTGPOOL.
When the storage pool occupancy exceeds the value for this parameter, ADSM can start migration, by node, to the next storage pool, as defined with the NEXTSTGPOOL parameter. You can specify HIGHMIG=100 to prevent migration for this storage pool (assuming you have defined the NEXTSTGPOOL parameter).
When the storage pool occupancy reaches the value for this parameter, ADSM does not initiate migration of another node's files. Because all file spaces that belong to a node are migrated together, the occupancy of the storage pool can fall below the value you specified for this parameter. You can set LOWMIG=0 to permit migration to empty the storage pool.
During migration, these processes are performed in parallel to provide the potential for improved migration rates.
Syntax for Updating a Primary Sequential Access Storage Pool
(1)
>>-UPDate STGpool-------poolname-------------------------------->
>---+------------------------------+---------------------------->
'-DESCription--=--description--'
>---+-----------------------------+----------------------------->
'-ACCess--=--+-READWrite---+--'
+-READOnly----+
'-UNAVailable-'
>---+------------------------------+---------------------------->
'-MAXSIze--=--+-maxfilesize-+--'
'-NOLimit-----'
>---+---------------------------+------------------------------->
'-NEXTstgpool--=--poolname--'
>---+------------------------------+---------------------------->
'-RECLAIMSTGpool--=--poolname--'
>---+---------------------------+--+-------------------------+-->
'-HIghmig--=--highmigvalue--' '-LOwmig--=--lowmigvalue--'
>---+------------------------------+---------------------------->
'-COLlocate--=--+-No--------+--'
+-Yes-------+
'-FILespace-'
>---+---------------------------+------------------------------->
'-REClaim--=--reclaimvalue--'
>---+---------------------------------+------------------------->
'-MAXSCRatch--=--maxscratchvalue--'
>---+----------------------+--+--------------------------------+-><
'-REUsedelay--=--days--' '-OVFLOcation--=--locationname---'
1 | You must specify at least one optional parameter on this command. |
Parameters for Updating a Primary Sequential Access Storage Pool
No new writes are permitted to the volumes in the storage pool from other volumes outside the storage pool. However, system processes (like reclamation) are permitted to move files within the volumes in the storage pool.
If this storage pool has been specified as a subordinate storage pool (with the NEXTSTGPOOL parameter) and is defined as readonly, the storage pool is skipped when system processes (like migration) attempt to write files to the storage pool from volumes in another storage pool.
No new writes are permitted to the volumes in the storage pool from other volumes outside the storage pool. However, system processes (like reclamation) are permitted to move files within the volumes in the storage pool. Files can also be moved or copied from this storage pool to another storage pool.
If this storage pool has been specified as a subordinate storage pool (with the NEXTSTGPOOL parameter) and is defined as unavailable, the storage pool is skipped when system processes (like migration) attempt to write files to the storage pool.
To limit the maximum physical file size, specify an integer (1 to 999999) followed by a scale factor. Scale factors and their meanings are:
For example, MAXSIZE=5G specifies that the maximum file size for this storage pool is 5 gigabytes.
If a file exceeds the maximum size and no pool is specified as the NEXTSTGPOOL, the file is not stored. If a file exceeds the maximum size and a pool is specified as the NEXTSTGPOOL, the file is stored in the next storage pool that can accept the file size. If you specify the NEXTSTGPOOL parameter, at least one storage pool in the hierarchy should have a MAXSIZE value of NOLIMIT. By setting MAXSIZE to NOLIMIT for at least one pool, you ensure that no matter what its size, a file can be stored somewhere.
To remove an existing storage pool from the storage hierarchy, specify a null string ("") for this value.
You cannot create a chain of storage pools that leads to an endless loop through the NEXTSTGPOOL parameter. At least one storage pool in the hierarchy must have no value specified for NEXTSTGPOOL.
Specifies another storage pool as a target for reclaimed data. This parameter is primarily for use with storage pools that have only one drive in its library. This parameter allows the volume to be reclaimed to be mounted in its library and the data is then moved to the specified reclaim storage pool.
This parameter must be an existing primary sequential storage pool. This parameter is optional, however, if this parameter is used all data will be reclaimed to that storage pool regardless of the number of drives in that library.
The reclaim storage pool itself must be defined as a primary storage pool. There are no restrictions on this storage pool's definition, but it should be defined with a NEXTSTGPOOL= value that will migrate its data back into the data storage hierarchy. Because its primary function is to collect reclaimed data, its NEXTSTGPOOL= value should be the same storage pool from which the data was reclaimed.
When the storage pool occupancy exceeds the value for this parameter, ADSM can start migration, by volume, to the next storage pool, as defined with the NEXTSTGPOOL parameter. You can specify HIGHMIG=100 to prevent migration for this storage pool (assuming you have defined the NEXTSTGPOOL parameter).
When the storage pool occupancy reaches the value for this parameter, ADSM does not initiate migration of files from another volume. Because all files that are on a single volume are migrated together, the occupancy of the storage pool can fall below the value you specified for the LOWMIG parameter. You can set LOWMIG=0 to permit migration to empty the storage pool.
Collocation reduces the number of sequential access media mounts for restore, retrieve, and recall operations. However, collocation increases both the amount of server time needed to collocate files for storing, and the number of volumes required. Collocation may not be useful on systems with only one or two sequential devices. For additional information, see ADSM Administrator's Guide.
Possible values are:
Space becomes fragmented as files on a volume are deleted because of processes such as expiration or file space deletion. The amount of space that can be reclaimed on a volume increases as files on the volume are deleted. When the percentage of space that can be reclaimed on a volume rises above the value for the RECLAIM parameter, the volume is reclaimed. Active files on the volume are rewritten to other volumes in the storage pool, making the original volume available for new files.
It is recommended that you specify a value of 50 percent or greater for this parameter so that files stored on two volumes can be combined onto a single output volume.
For offsite storage pool volumes, when a copy pool volume that is offsite becomes eligible for reclamation, the reclamation process attempts to retrieve the active files on the reclaimable volume from a primary or copy storage pool that is onsite, and then write these files to an available volume in the original copy storage pool. Effectively, these files are moved back to the onsite location, although they could be obtained from the offsite volume after a disaster if a database backup is used which references the files on the offsite volume. Because of the way reclamation works with offsite volumes, use it carefully with copy storage pools.
Notes:
To allow applications using ADSM to store data to WORM optical media, storage pools can now be assigned to device classes of WORM, WORM12, or WORM14. This ensures that any volumes assigned to the storage pool are of the WORM media type.
However, once a sector of WORM optical media has been written to, it can not be written over. This prevents WORM volumes from being reclaimed. So, when storage pools are defined to a WORM device class the default reclaim value is set to 100 to prevent reclamation from occurring.
The standard default of 60 will still be used for the storage pool being assigned to a device class with a device type of OPTICAL. However, if the storage pool is being assigned to a device class with a device type of WORM, then the default reclaim value of 100 will be used.
Users will be allowed to specify a value other than the default regardless of the device type of the device class. This will allow users with storage pools assigned to device type of WORM to consolidate data onto fewer volumes, and free slots in automated libraries.
If you do not specify a value for this parameter, no scratch media are requested by ADSM.
Scratch volumes are automatically deleted from the storage pool when they become empty. When scratch volumes with the device type of FILE are deleted, the space that the volumes occupied is freed by ADSM and returned to the file system.
By specifying this parameter, you can ensure that the database could be restored to an earlier level and database references to files in the storage pool would still be valid.
Syntax for Updating a Copy Storage Pool
(1)
>>-UPDate STGpool-------poolname-------------------------------->
>---+------------------------------+---------------------------->
'-DESCription--=--description--'
>---+-----------------------------+----------------------------->
'-ACCess--=--+-READWrite---+--'
+-READOnly----+
'-UNAVailable-'
>---+------------------------------+---------------------------->
'-COLlocate--=--+-No--------+--'
+-Yes-------+
'-FILespace-'
>---+---------------------------+------------------------------->
'-REClaim--=--reclaimvalue--'
>---+---------------------------------+------------------------->
'-MAXSCRatch--=--maxscratchvalue--'
>---+----------------------+--+--------------------------------+-><
'-REUsedelay--=--days--' '-OVFLOcation--=--locationname---'
1 | You must specify at least one optional parameter on this command. |
Parameters for Updating a Copy Storage Pool
No new writes are permitted to the volumes in the copy storage pool from other volumes outside the copy storage pool. However, system processes (like reclamation) are permitted to move files within the volumes in the storage pool. Files cannot be backed up to the copy storage pool, but existing backup copies can be restored.
No new writes are permitted to the volumes in the copy storage pool from other volumes outside the copy storage pool. However, system processes (like reclamation) are permitted to move files within the volumes in the copy storage pool. Files cannot be backed up to the copy storage pool, but existing backup copies can be restored.
Collocation reduces the number of sequential access media mounts for restore, retrieve, and recall operations. However, collocation increases both the amount of server time needed to collocate files for storing, and the number of volumes required. Collocation may not be useful on systems with only one or two sequential devices. For additional information, see ADSM Administrator's Guide.
Possible values are:
The amount of space that can be reclaimed on a volume increases as files on the volume are deleted because of processes such as expiration or file space deletion. It is recommended that you specify a value of 50 percent or greater for this parameter so that files stored on two volumes can be combined onto a single output volume.
When reclamation occurs and how reclamation processing is done depends on whether the volumes are marked as offsite.
For volumes that are not marked as offsite volumes, reclamation can occur only after the volume has been filled, and then begins to empty because of file deletion. When the percentage of reclaimable space on a volume that had once been full rises above the value for the RECLAIM parameter, the volume is reclaimed. Active files on the volume are rewritten to other volumes in the storage pool, making the original volume available for new files.
For offsite volumes, reclamation can occur regardless of whether the volume has ever been filled. An offsite volume is eligible for reclamation when the percentage of unused space on the volume is greater than the reclaim parameter value. The unused space includes both space that has never been used on the volume and space that has become empty because of file deletion.
Reclamation processing also works differently for offsite storage pool volumes. When a copy pool volume that is offsite becomes eligible for reclamation, the reclamation process attempts to retrieve the active files on the reclaimable volume from a primary or copy storage pool that is onsite, and then write these files to an available volume in the original copy storage pool. Effectively, these files are moved back to the onsite location, although they could be obtained from the offsite volume after a disaster if a database backup is used which references the files on the offsite volume. Because of the way reclamation works with offsite volumes, use it carefully with copy storage pools.
Notes:
To allow applications using ADSM to store data to WORM optical media, storage pools can now be assigned to device classes of WORM, WORM12, or WORM14. This ensures that any volumes assigned to the storage pool are of the WORM media type.
However, once a sector of WORM optical media has been written to, it can not be written over. This prevents WORM volumes from being reclaimed. So, when storage pools are defined to a WORM device class the default reclaim value is set to 100 to prevent reclamation from occurring.
The standard default of 60 will still be used for the storage pool being assigned to a device class with a device type of OPTICAL. However, if the storage pool is being assigned to a device class with a device type of WORM, then the default reclaim value of 100 will be used.
Users will be allowed to specify a value other than the default regardless of the device type of the device class. This will allow users with storage pools assigned to device type of WORM to consolidate data onto fewer volumes, and free slots in automated libraries.
If you do not specify a value for this parameter, no scratch media are requested by ADSM.
A scratch volume is automatically deleted from the copy pool after all files have been deleted and the time specified by the REUSEDELAY parameter has elapsed. However, if the access mode for a scratch volume is OFFSITE, the volume is not deleted from the copy pool until the access mode is changed; this allows an administrator to query ADSM for empty, offsite scratch volumes and return these to the onsite location.
When scratch volumes with the device type of FILE become empty and are deleted, the space that the volumes occupied is freed by ADSM and returned to the file system.
| Important: | By specifying this parameter, you can ensure that the database can be restored to an earlier level and database references to files in the copy storage pool are still valid. For this to happen, you must set this parameter to a value greater than the number of days you plan on retaining the oldest database backup. If you change the value for this parameter, the value for the SET DRMDBBACKUPEXPIREDAYS parameter should also be changed to match the new value. For additional information, refer to ADSM Administrator's Guide. |
Examples
Task 1
Update the primary storage pool named POOL1 to permit as many as 10 scratch volumes to be mounted.
Task 2
Update the primary storage pool named BACKUPPOOL to permit caching.
Task 3
Update the copy storage pool namedCPOOL1 to permit as many as 10 scratch volumes to be mounted and to collate files.
Related Commands
Table 248. Commands Related to UPDATE STGPOOL
| Command | Description |
|---|---|
| BACKUP DB | Backs up the ADSM database to sequential access volumes. |
| BACKUP STGPOOL | Backs up a primary storage pool to a copy storage pool. |
| DEFINE STGPOOL | Defines a storage pool as a named collection of server storage media. |
| DELETE STGPOOL | Deletes a storage pool from server storage. |
| MOVE DRMEDIA | Moves DRM media onsite and offsite. |
| QUERY DRMEDIA | Displays information about disaster recovery volumes. |
| QUERY STGPOOL | Displays information about one or more storage pools. |
| RESTORE STGPOOL | Restores files to a primary storage pool from copy storage pools. |
| RESTORE VOLUME | Restores files stored on specified volumes in a primary storage pool from copy storage pools. |
| SET DRMDBBACKUPEXPIREDAYS | Specifies criteria for database backup series expiration. |