- pool_name (Required)
- Specifies the name of the storage pool to be defined. The name
must be unique, and the maximum length is 30 characters.
- device_class_name (Required)
- Specifies the name of the sequential access device class to which
this copy storage pool is assigned. You can specify any device class
except DISK.
- POoltype=COpy (Required)
- Specifies that you want to define a copy storage pool.
- DESCription
- Specifies a description of the copy storage pool. This parameter
is optional. The maximum length of the description is 255 characters.
Enclose the description in quotation marks if it contains any blank
characters.
- ACCess
- Specifies how client nodes and server processes (such as reclamation)
can access files in the copy storage pool. This parameter is optional.
The default value is READWRITE. Possible values are:
- READWrite
- Specifies that files can be read from and written to the volumes
in the copy storage pool.
- READOnly
- Specifies that client nodes can read files that are stored only
on the volumes in the copy storage pool.
Server processes can
move files within the volumes in the storage pool. The server can
use files in the copy storage pool to restore files to primary storage
pools. However, no new writes are permitted to volumes in the copy
storage pool from volumes outside the storage pool. A storage pool
cannot be backed up to the copy storage pool.
- UNAVailable
- Specifies that client nodes cannot access files that are stored
on volumes in the copy storage pool.
Server processes can move
files within the volumes in the storage pool. The server can use files
in the copy storage pool to restore files to primary storage pools.
However, no new writes are permitted to volumes in the copy storage
pool from volumes outside the storage pool. A storage pool cannot
be backed up to the copy storage pool.
- COLlocate
- Specifies
whether the server attempts to keep data, stored on as few volumes
as possible, that belong to one of the following candidates:
- A single client node
- A group of file spaces
- A group of client nodes
- A client file space
This parameter is optional. The default value is NO. Collocation
reduces the number of sequential access media mounts for restore,
retrieve, and recall operations. However, collocation increases both
the amount of server time that is needed to collocate files for storing
and the number of volumes required. Collocation can also impact the
number of processes migrating disks to sequential pool.
You can specify one of the following options:
- No
- Specifies that collocation is disabled. During
migration from disk, processes are created at a file space level.
- GRoup
- Specifies that collocation is enabled at the group
level for client nodes or file spaces. For collocation groups, the
server attempts to put data for nodes or file spaces that belong to
the same collocation group on as few volumes as possible.
If you
specify COLLOCATE=GROUP but do not define any collocation groups,
or if you do not add nodes or file spaces to a collocation group,
data is collocated by node. Consider tape usage when you organize
client nodes or file spaces into collocation groups.
For example,
if a tape-based storage pool consists of data from nodes and you specify
COLLOCATE=GROUP, the server completes the following actions:
- Collocates the data by group for grouped nodes. Whenever possible,
the server collocates data that belongs to a group of nodes on a single
tape or on as few tapes as possible. Data for a single node can also
be spread across several tapes that are associated with a group.
- Collocates the data by node for ungrouped nodes. Whenever possible,
the server stores the data for a single node on a single tape. All
available tapes that already have data for the node are used before
available space on any other tape is used.
- During migration from disk, the server creates migration processes
at the collocation group level for grouped nodes, and at the node
level for ungrouped nodes.
If a tape-based storage pool consists of data from grouped
file spaces and you specify COLLOCATE=GROUP, the server completes
the following actions:
- Collocates by group, the data for grouped file spaces only. Whenever
possible, the server collocates data that belongs to a group of file
spaces on a single tape or on as few tapes as possible. Data for a
single file space can also be spread across several tapes that are
associated with a group.
- Collocates the data by node (for file spaces that are not explicitly
defined to a file space collocation group). For example, node1 has
file spaces named A, B, C, D, and E. File spaces A and B belong to
a filespace collocation group but C, D, and E do not. File spaces
A and B are collocated by filespace collocation group, while C, D,
and E are collocated by node.
- During migration from disk, the server creates migration processes
at the collocation group level for grouped file spaces.
Data is collocated on the least amount of sequential access
volumes.
- NODe
- Specifies that collocation is enabled at the client node level.
For collocation groups, the server attempts to put data for one node
on as few volumes as possible. If the node has multiple file spaces,
the server does not try to collocate those file spaces. For compatibility
with an earlier version, COLLOCATE=YES is still accepted by the server
to specify collocation at the client node level.
If a storage pool
contains data for a node that is a member of a collocation group and
you specify COLLOCATE=NODE, the data is collocated by node.
For COLLOCATE=NODE, the server creates processes at
the node level when you migrate data from disk.
- FIlespace
- Specifies that collocation is enabled at the file
space level for client nodes. The server attempts to place data for
one node and file space on as few volumes as possible. If a node has
multiple file spaces, the server attempts to place data for different
file spaces on different volumes.
For COLLOCATE=FILESPACE, the
server creates processes at the file space level when you migrate
data from disk.
- REClaim
- Specifies
when the server reclaims a volume, which is based on the percentage
of reclaimable space on a volume. Reclaimable space is the amount
of space that is occupied by files that are expired or deleted from
the Tivoli® Storage
Manager database.
Reclamation
makes the fragmented space on volumes usable again by moving any remaining
unexpired files from one volume to another volume, thus making the
original volume available for reuse. This parameter is optional. You
can specify an integer from 1 to 100. The default value is 100, which
means that reclamation is not completed.
When determining which volumes in a storage pool to
reclaim, the Tivoli Storage
Manager server
first determines the reclamation threshold indicated by the RECLAIM.
The server then examines the percentage of reclaimable space for each
volume in the storage pool. If the percentage of reclaimable space
on a volume is greater that the reclamation threshold of the storage
pool, the volume is a candidate for reclamation.
For
example, suppose storage pool FILEPOOL has a reclamation threshold
of 70 percent. This value indicates that the server can reclaim any
volume in the storage pool that has a percentage of reclaimable space
that is greater that 70 percent. The storage pool has three volumes:
- FILEVOL1 with 65 percent reclaimable space
- FILEVOL2 with 80 percent reclaimable space
- FILEVOL3 with 95 percent reclaimable space
When reclamation begins, the server compares
the percent of reclaimable space for each volume with the reclamation
threshold of 70 percent. In this example, FILEVOL2 and FILEVOL3 are
candidates for reclamation because their percentages of reclaimable
space are greater than 70. To determine the percentage of reclaimable
space for a volume, issue the QUERY VOLUME command
and specify FORMAT=DETAILED. The value in the
field Pct. Reclaimable Space is the percentage of reclaimable space
for the volume.
If you change the
value from the default, specify a value of 50 percent or greater so
that files stored on two volumes can be combined onto a single output
volume.
When a copy pool volume that is offsite becomes eligible
for reclamation, the reclamation process attempts to obtain the unexpired
files on the reclaimable volume from a primary or copy storage pool
that is onsite. The process then writes these files to an available
volume in the original copy storage pool. Effectively, these files
are moved back to the onsite location. However, the files can be obtained
from the offsite volume after a disaster if a database backup is used
that references the files on the offsite volume. Because of the way
reclamation works with offsite volumes, use it carefully with copy
storage pools.
- RECLAIMPRocess
- Specifies
the number of parallel processes to use for reclaiming the volumes
in this storage pool. This parameter is optional. Enter a value
from 1 to 999. The default value is 1.
When calculating the value for
this parameter, consider the number of sequential storage pools that
will be involved with the reclamation and the number of logical and
physical drives that can be dedicated to the operation. To access
a sequential access volume, IBM® Tivoli Storage Manager uses
a mount point and, if the device type is not FILE, a physical drive.
The number of available mount points and drives depends on other Tivoli Storage
Manager and system
activity and on the mount limits of the device classes for the sequential
access storage pools that are involved in the reclamation.
For example, suppose
that you want to reclaim the volumes from two sequential storage pools
simultaneously and that you want to specify four processes for each
of the storage pools. The storage pools have the same device class.
Each process requires two mount points and, if the device type is
not FILE, two drives. (One of the drives is for the input volume,
and the other drive is for the output volume.) To run eight reclamation
processes simultaneously, you need a total of at least 16 mount points
and 16 drives. The device class for the storage pools must have a
mount limit of at least 16.
If the number of reclamation processes you specify is
more than the number of available mount points or drives, the processes
that do not obtain mount points or drives will wait for mount points
or drives to become available. If mount points or drives do not become
available within the MOUNTWAIT time, the reclamation processes will
end. For information about specifying the MOUNTWAIT time, see DEFINE DEVCLASS (Define a device class).
The Tivoli Storage
Manager server
will start the specified number of reclamation processes regardless
of the number of volumes that are eligible for reclamation. For example,
if you specify ten reclamation processes and only six volumes are
eligible for reclamation, the server will start ten processes and
four of them will complete without processing a volume.
- RECLAMATIONType
- Specifies the method by
which volumes are reclaimed and managed. This parameter is optional.
The default value is THRESHOLD. Possible values are the following:
- THRESHold
- Specifies that volumes that belong to this storage pool are reclaimed
based on the threshold value in the RECLAIM attribute for this storage
pool.
- SNAPlock
- Specifies that FILE volumes that
belong to this storage pool will be managed for retention using NetApp
Data ONTAP software and NetApp SnapLock volumes. This parameter is
only valid for storage pools that being defined to a server that has
data retention protection that is enabled and that is assigned to
a FILE device class. Volumes in this storage pool are not reclaimed
based on threshold; the RECLAIM value for the storage pool is ignored.
All
volumes in this storage pool are created as FILE volumes. A retention
date, which is derived from the retention attributes in the archive
copy group for the storage pool, is set in the metadata for the FILE
volume using the SnapLock feature of the NetApp Data ONTAP operating
system. Until the retention date expires, the FILE volume and any
data on it cannot be deleted from the physical SnapLock volume on
which it is stored.
The RECLAMATIONTYPE parameter
for all storage pools being defined must be the same when defined
to the same device class name. The DEFINE command
fails if the RECLAMATIONTYPE parameter specified
is different from what is defined for storage pools that are already
defined to the device class name.
- OFFSITERECLAIMLimit
- Specifies the number of
offsite volumes to have their space reclaimed during reclamation for
this storage pool. This parameter is optional. The default value is
NOLIMIT. Possible values are:
- NOLimit
- Specifies that you want to have the space reclaimed in all of
your offsite volumes.
- number
- Specifies the number of offsite volumes to have their space reclaimed.
You can specify an integer from 0 to 99999. A value of zero means
that none of the offsite volumes will be reclaimed.
Important: When determining the value for the OFFSITERECLAIMLIMIT,
consider using the statistical information in the message issued at
the end of the offsite volume reclamation operation. Alternatively,
you can use the following
Tivoli Storage
Manager SQL select
command to obtain the statistical information from the SUMMARY table
for the offsite volume reclamation operation:
select * from summary where activity='OFFSITE RECLAMATION'
The statistical information includes the following items:
- The number of offsite volumes that were processed
- The number of parallel processes that were used
- The total amount of time required for the processing
The order in which offsite volumes
are reclaimed is based on the amount of unused space in a volume.
(Unused space includes both space that has never been used on the
volume and space that has become empty because of file deletion.)
Volumes with the largest amount of unused space are reclaimed first.
For example, suppose a copy storage pool contains three
volumes: VOL1, VOL2, and VOL3. VOL1 has the largest amount of unused
space, and VOL3 has the least amount of unused space. Suppose further
that the percentage of unused space in each of the three volumes is
greater than the value of the RECLAIM parameter.
If you do not specify a value for the OFFSITERECLAIMLIMIT parameter,
all three volumes will be reclaimed when the reclamation runs. If
you specify a value of 2, only VOL1 and VOL2 will be reclaimed when
the reclamation runs. If you specify a value of 1, only VOL1 will
be reclaimed.
- MAXSCRatch (Required)
- Specifies the maximum number of scratch volumes that the server
can request for this storage pool. You can specify an integer from
0 to 100000000. By allowing the server to request scratch volumes
as needed, you avoid having to define each volume to be used.
The
value specified for this parameter is used to estimate the total number
of volumes available in the copy storage pool and the corresponding
estimated capacity for the copy storage pool.
Scratch volumes
are automatically deleted from the storage pool when they become empty.
However, if the access mode for a scratch volume is OFFSITE, the volume
is not deleted from the copy storage pool until the access mode is
changed. This allows an administrator to query the server 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 the server
and returned to the file system.
Tip: For server-to-server
operations that use virtual volumes and that store a small amount
of data, consider specifying a value for the MAXSCRATCH parameter
that is higher than the value you typically specify for write operations
to other types of volumes. After a write operation to a virtual volume, Tivoli Storage
Manager marks the
volume as FULL, even if the value of the MAXCAPACITY parameter
on the device-class definition has not been reached. The Tivoli Storage
Manager server does
not keep virtual volumes in FILLING status and does not append to
them. If the value of the MAXSCRATCH parameter
is too low, server-to-server operations can fail.
- REUsedelay
- Specifies the
number of days that must elapse after all files are deleted from a
volume before the volume can be rewritten or returned to the scratch
pool. This parameter is optional. You can specify an integer from
0 to 9999. The default value is 0, which means that a volume can be
rewritten or returned to the scratch pool as soon as all the files
are deleted from the volume.
Important: Use
this parameter to help ensure that when you restore the database to
an earlier level, database references to files in the copy storage
pool are still valid. You must set this parameter to a value greater
than the number of days you plan to retain the oldest database backup.
The number of days that are specified for this parameter should be
the same as the number specified for the SET DRMDBBACKUPEXPIREDAYS command.
- OVFLOcation
- Specifies the overflow location for the storage pool. The server
assigns this location name to a volume that is ejected from the library
by the command. This parameter is optional. The location name can
be a maximum length of 255 characters. Enclose the location name in
quotation marks if the location name contains any blank characters.
- DATAFormat
- Specifies the data format to use to back up
files to this storage pool and restore files from this storage pool.
The default format is the NATIVE server format. Possible values are:
- NATive
- Specifies the data format is the native IBM Tivoli Storage Manager server
format and includes block headers.
- NONblock
- Specifies the data format is the native IBM Tivoli Storage Manager server
format and does not include block headers.
Important: The
default minimum block size on a volume associated with a FILE device
class is 256 KB, regardless how much data is being written to the
volume. For certain tasks (for example, using content-management products,
using the DIRMC client option to store directory information, or migrating
very small files using Tivoli Storage
Manager for Space Management or Tivoli Storage
Manager HSM for Windows), you can minimize wasted
space on storage volumes by specifying the NONBLOCK data format.
In most situations, however, the NATIVE format is preferred.
- NETAPPDump
- Specifies that the data is in a NetApp dump format. Do not specify
this data format for file system images that are in a dump format
and that have been backed up from a NetApp file server using NDMP.
The server will not complete storage pool reclamation or AUDIT
VOLUME for a storage pool with DATAFORMAT=NETAPPDUMP. You
can use the MOVE DATA command to move NDMP-generated
data out of a volume if the volume must be reused.
- CELERRADump
- Specifies that the data is in an EMC Celerra dump format. Do
not specify this data format for file system images that are in a
dump format and that have been backed up from an EMC Celerra file
server using NDMP. The server will not complete storage pool reclamation
or AUDIT VOLUME for a storage pool with DATAFORMAT=CELERRADUMP.
You can use the MOVE DATA command to move NDMP-generated
data out of a volume if the volume must be reused.
- NDMPDump
- Specifies that the data is in a NAS vendor-specific backup format.
Do not specify this data format for file system images that are in
a backup format and that have been backed up from a NAS file server
other than a NetApp or EMC Celerra file server. The server will not
complete storage pool reclamation or AUDIT VOLUME for
a storage pool with DATAFORMAT=NDMPDUMP. You can use the MOVE
DATA command to move NDMP-generated data out of a volume
if the volume must be reused.
- CRCData
- Specifies whether a cyclic
redundancy check (CRC) validates storage pool data when audit volume
processing occurs on the server. This parameter is only valid for
NATIVE data format storage pools. This parameter is optional. The
default value is NO. By setting CRCDATA to YES and scheduling an AUDIT
VOLUME command you can continually ensure the integrity
of data that is stored in your storage hierarchy. Possible values
are:
- Yes
- Specifies that data is stored containing CRC information, allowing
for audit volume processing to validate storage pool data. This mode
impacts performance because additional overhead is required to calculate
and compare CRC values between the storage pool and the server.
- No
- Specifies that data is stored without CRC information.
Tip: For storage pools
that are associated with the 3592, LTO,
or ECARTRIDGE device type, logical block protection provides better
protection against data corruption than CRC validation for a storage
pool. If you specify CRC validation for a storage pool, data is validated
only during volume auditing operations. Errors are identified after
data is written to tape.
To enable logical block protection, specify
a value of READWRITE for the
LBPROTECT parameter
on the
DEFINE DEVCLASS and
UPDATE DEVCLASS commands
for the 3592, LTO, or ECARTRIDGE
device types. Logical block protection is supported only on the following
types of drives and media:
- IBM LTO5 and later.
- IBM 3592 Generation 3 drives
and later with 3592 Generation 2 media and later.
- Oracle StorageTek T10000C drives.
- DEDUPlicate
- Specifies whether the data that
is stored in this storage pool will be deduplicated. This parameter
is optional and is valid only for storage pools that are defined
with a FILE-type device class. The default value is NO.
- IDENTIFYPRocess
- Specifies the number of parallel processes to
use for server-side duplicate identification. This parameter is optional
and is valid only for storage pools that are defined with a FILE device
class. Enter a value from 0 to 50.
The default
value for this parameter is 0. Duplicate-identification processes
for a copy storage pool are not necessary if you specify duplicate-identification
processes for the primary storage pool. When Tivoli Storage
Manager analyzes
a file in a storage pool, Tivoli Storage
Manager also analyzes
the file in all other storage pools.
When
calculating the value for this parameter, consider the workload on
the server and the amount of data requiring data deduplication. Server-side
duplicate identification requires disk I/O and processor resources,
so the more processes you allocate to data deduplication, the heavier
the workload that you place on your system. In addition, consider
the number of volumes that require processing. Server-side duplicate-identification
processes work on volumes containing data that requires deduplication.
If you update a storage pool, specifying that the data in the storage
pool is to be deduplicated, all the volumes in the pool require processing.
For this reason, you might have to define a high number of duplicate-identification
processes initially. Over time, however, as existing volumes are processed,
only the volumes containing new data have to be processed. When that
happens, you can reduce the number of duplicate-identification processes.
Remember: Duplicate-identification processes
can be either active or idle. Processes that are working on files
are active. Processes that are waiting for files to work on are idle.
Processes remain idle until volumes with data to be deduplicated become
available. The output of the QUERY PROCESS command
for a duplicate-identification process includes the total number of
bytes and files that have been processed since the process first started.
For example, if a duplicate-identification process processes four
files, becomes idle, and then processes five more files, then the
total number of files processed is nine. Processes end only when canceled
or when the number of duplicate-identification processes for the storage
pool is changed to a value less than the number currently specified.