Modifying the amount of available memory for Copy Services, Volume Mirroring, and RAID arrays by using the CLI

You can use the command-line interface (CLI) to modify the amount of memory that is available for RAID arrays, the volume mirroring feature, and the FlashCopy®, Metro Mirror, or Global Mirror Copy Services features.

About this task

Copy Services features and RAID require that small amounts of volume cache be converted from cache memory into bitmap memory to allow the functions to operate. If you do not have enough bitmap space allocated when you try to use one of the functions, you will not be able to complete the configuration.

The total memory that can be dedicated to these functions is not defined by the physical memory in the system. The memory is constrained by the software functions that use the memory.

In planning the installation for a system, consider the future requirements for the advanced functions. Review the following tables to calculate the memory requirements and confirm that your system is able to accommodate the total installation size.

The following tables describe the amount of bitmap space necessary to configure the various copy services functions and RAID.

This table provides an example of the amount of memory that is required for remote mirroring functions, FlashCopy functions, and volume mirroring.

Table 1. Examples of memory required
Function Grain size 1 MiB of memory provides the following volume capacity for the specified I/O group
Remote copy 256 KiB 2 TiB of total Metro Mirror, Global Mirror, or HyperSwap® volume capacity
FlashCopy 256 KiB 2 TiB of total FlashCopy source volume capacity
FlashCopy 64 KiB 512 GiB of total FlashCopy source volume capacity
Incremental FlashCopy 256 KiB 1 TiB of total incremental FlashCopy source volume capacity
Incremental FlashCopy 64 KiB 256 GiB of total incremental FlashCopy source volume capacity
Volume mirroring 256 KiB 2 TiB of mirrored volume capacity
Note:
  1. For multiple FlashCopy targets, you must consider the number of mappings. For example, for a mapping with a grain size of 256 KiB, 8 KiB of memory allows one mapping between a 16 GiB source volume and a 16 GiB target volume. Alternatively, for a mapping with a 256 KiB grain size, 8 KiB of memory allows two mappings between one 8 GiB source volume and two 8 GiB target volumes.
  2. When creating a FlashCopy mapping, if you specify an I/O group other than the I/O group of the source volume, the memory accounting goes toward the specified I/O group, not toward the I/O group of the source volume.
  3. For volume mirroring, the full 512 MiB of memory space enables 1 PiB of total volume mirroring capacity.
  4. When creating new FlashCopy relationships or mirrored volumes, additional bitmap space is allocated automatically by the system if required.
Table 2 provides an example of RAID level comparisons with their bitmap memory cost, where MS is the size of the member drives and MC is the number of member drives.
Table 2. RAID level comparisons
Level Member count Approximate capacity Redundancy Approximate bitmap memory cost
RAID-0 1-8 MC * MS None (1 MB per 2 TB of MS) * MC
RAID-1 2 MS 1 (1 MB per 2 TB of MS) * (MC/2)
RAID-5 3-16 (MC-1) * MS 1 1 MB per 2 TB of MS with a strip size of 256 KB; double with strip size of 128 KB.
RAID-6 5-16 less than (MC-2 * MS) 2
RAID-10 2-16 (evens) MC/2 * MS 1 (1 MB per 2 TB of MS) * (MC/2)
Note: There is a margin of error on the approximate bitmap memory cost of approximately 15%. For example, the cost for a 256 KB strip size for RAID-5 is ~1.15 MB for the first 2 TB of MS.
Before you specify the configuration changes, consider the following factors.
  • For FlashCopy mappings, only one I/O group consumes bitmap space. By default, the I/O group of the source volume is used.
  • For Metro Mirror, Global Mirror, and HyperSwap active-active relationships, two bitmaps exist. For Metro Mirror or Global Mirror relationships, one is used for the master clustered system and one is used for the auxiliary system because the direction of the relationship can be reversed. For active-active relationships, which are configured automatically when HyperSwap volumes are created, one bitmap is used for the volume copy on each site because the direction of these relationships can be reversed.
  • When you create a reverse mapping; for example, to run a restore operation from a snapshot to its source volume; a bitmap is also created for this reverse mapping.
  • When you configure change volumes for use with Global Mirror or Metro Mirror, two internal FlashCopy mappings are created for each change volume.
  • The smallest possible bitmap is 4 KiB; therefore, a 512 byte volume requires 4 KiB of bitmap space.
On existing systems, also consider these factors:
  • When you create FlashCopy mappings and mirrored volumes, HyperSwap volumes, or formatted, fully allocated volumes, the system attempts to automatically increase the available bitmap space. You do not need to manually increase this space.
  • Metro Mirror and Global Mirror relationships do not automatically increase the available bitmap space. You might need to use the chiogrp command to manually increase the space in one or both of the master and auxiliary systems.
  • If you create and then delete many of these objects, consider using the chiogrp command to reduce the memory that is reserved for these functions and release that memory for another use.

To modify and verify the amount of memory that is available, complete the following steps:

Procedure

  1. Issue the following command to modify the amount of memory that is available for Volume Mirroring or a Copy Service feature:
    chiogrp -feature flash |remote | mirror -size memory_size io_group_id | io_group_name

    where flash | remote | mirror is the feature that you want to modify, memory_size is the amount of memory that you want to be available, and io_group_id | io_group_name is the ID or name of the I/O group for which you want to modify the amount of available memory.

  2. Issue the following command to verify that the amount of memory has been modified:
    lsiogrp object_id | object_name

    where object_id | object_name is the ID or name of the I/O group for which you have modified the amount of available memory.

    The following information is an example of the output that is displayed.

    id 0
name io_grp0
node_count 2
vdisk_count 40
host_count 1
flash_copy_total_memory 5.0MB
flash_copy_free_memory 5.0MB
remote_copy_total_memory 20.0MB
remote_copy_free_memory 20.0MB
mirroring_total_memory 20.0MB
mirroring_free_memory 20.0MB
raid_total_memory 40.0MB
raid_free_memory 0.1MB
maintenance no
compression_active no
accessible_vdisk_count 40
compression_supported yes
max_enclosures 21
encryption_supported yes
Parent topic: Managing I/O groups