Volumes
A volume is a logical disk that the system presents to attached hosts.
Application servers access volumes, not MDisks or drives. To keep a volume accessible even when an MDisk on which it depends has become unavailable, a mirrored copy can be added to a selected volume. Each volume can have a maximum of two copies. Each volume copy is created from a set of extents in a pool.
You can create different types of volumes, depending on the type of topology that is supported and configured on your system. All systems support standard topology, which is a single-site configuration. For systems with single-site configuration, you can create basic, mirrored, or custom volumes. If you have a HyperSwap® topology, which is also a multiple-site configuration, you can create basic, HyperSwap, or custom volumes. The system supports several capacity savings methods, such as thin-provisioning and compression. Thin provisioning creates a volume with more virtual than provisioned capacity that allows the capacity to grow as it is needed. With compressed volumes, data is compressed as it is written to the volume, which saves capacity on the volume. Deduplication can be configured with volumes that use different capacity saving methods, such as thin-provisioning. Deduplicated volumes must be created in data reduction pools for added capacity savings. Deduplication is a type of data reduction that eliminates duplicate copies of data. Deduplication of user data occurs within a data reduction pool and only between volumes or volume copies that are marked as deduplicated. Some models or software versions require specific hardware or software to use this function. For more information, see planning data reduction pools and deduplication. If you select to deduplicate volume data in a multi-site topology, the volume copies must be in data reduction pools on both sites.
Volumes can be assigned to an ownership group. An ownership group defines a subset of users and objects within the system. You can create ownership groups to further restrict access to specific resources that are defined in the ownership group. Only users with Security Administrator roles can configure and manage ownership groups.
- The volume inherits the ownership group of the child pools that provide capacity for the volume and its copies. Volume copies can be created in different ownership groups for backup up scenarios. However, this value must be set intentionally by users that are not defined in ownership groups. When you create a volume copy or migrate volumes to other pools, you can specify child pools that are defined in different ownership groups in the management GUI, which establishes inconsistent ownership. When creating a volume copy or migrating a volume in the command-line interface, use the -inconsistentownershipgroup to allow for inconsistent ownership groups. However, it is not recommended to leave volumes or volume copies in different ownership groups. After the migration, the user with Security Administrator role needs to ensure all volumes or copies are within the same ownership group as the users who need access.
- With volume groups, the volume group and its volumes can belong to different ownership groups. However, the ownership of a volume group does not impact the ownership of the volumes that it contains.
Types
You can use more sophisticated extent allocation policies to create volume copies. When you create a striped volume, you can specify the same MDisk more than once in the list of MDisks that are used as the stripe set. This allocation is useful if you have a storage pool in which not all the MDisks are of the same capacity. For example, if you have a storage pool that has two 18 GB MDisks and two 36 GB MDisks, you can create a striped volume copy by specifying each of the 36 GB MDisks twice in the stripe set so that two-thirds of the storage is allocated from the 36 GB disks.
If you delete a volume, you destroy access to the data that is on the volume. The extents that were used in the volume are returned to the pool of free extents that is in the storage pool. The deletion might fail if the volume is still mapped to hosts. The deletion might also fail if the volume is still part of a FlashCopy®, Metro Mirror, or Global Mirror mapping. If the deletion fails, you can specify the force-delete flag to delete both the volume and the associated mappings to hosts. Forcing the deletion deletes the Copy Services relationship and mappings.
States
This table describes the different possible states of a volume.
State | Description |
---|---|
Online | At least one synchronized copy of the volume is online and available if both nodes in the I/O group can access the volume. A single node can access a volume only if it can access all the MDisks in the storage pool that are associated with the volume. |
Offline | The volume is offline and unavailable if both nodes in the I/O group are missing, or if none of the nodes in the I/O group that are present can access any synchronized copy of the volume. The volume can also be offline if the volume is the secondary of a Metro Mirror or Global Mirror relationship that is not synchronized. A thin-provisioned volume goes offline if a user attempts to write an amount of data that exceeds the available disk space. |
Degraded | The status of the volume is degraded if one node in the I/O group is
online and the other node is either missing or cannot access any synchronized copy of the
volume.
Note: If
a volume is degraded and all of the associated nodes and MDisks are online, call your
support center for assistance.
|
Deleting | For thin-provisioned or compressed volume copies in data reduction
pools, the deleting status indicates that copies are being deleted. All volume copies,
including fully allocated copies, are not accessible until the delete operation completes.
In addition, several operations cannot be started until all copies are deleted. The
following commands are restricted if one copy of a volume is in the process of being deleted:
|
Cache modes
You can select to have read and write operations that are stored in cache by specifying a cache mode. You can specify the cache mode when you create the volume. After the volume is created, you can change the cache mode.
This table describes the types of cache modes for a volume.
Cache mode | Description |
---|---|
readwrite | All read and write I/O operations that are performed by the volume are
stored in cache. This is the default cache mode for all volumes. A
volume or volume copy created from a data reduction pool must have a cache mode of
readwrite. If you try to create a thin provisioned or compressed volume copy from a data
reduction pool and the volume cache mode is not readwrite , the operation
fails. |
readonly | All read I/O operations that are performed by the volume are stored in cache. |
none | All read and write I/O operations that are performed by the volume are not stored in cache. |