Document revision date: 15 July 2002

This chapter describes the minicopy feature of Compaq Volume Shadowing for OpenVMS introduced in OpenVMS Version 7.3. Minicopy and its enabling technology, write bitmaps, are fully implemented on OpenVMS Alpha systems. OpenVMS VAX nodes can write to shadow sets that use this feature but they can neither create master write bitmaps nor manage them with DCL commands. In a mixed-architecture OpenVMS Cluster system, only one Alpha system is required in order to use minicopy.

The primary purpose of minicopy is to shorten the time it takes to return a shadow set member to the shadow set. The shadow set member is typically removed for the purpose of backing up the data and is then returned to membership in the shadow set.

7.1 What Is Minicopy?

A minicopy operation is a streamlined copy operation. Minicopy ensures that the data on a shadow set member, when returned to the shadow set, is identical to the data in the shadow set.

A write bitmap tracks writes to a shadow set and is used to direct a minicopy operation when a shadow set member is returned to the shadow set.

Prior to the removal of a shadow set member, application writes are sent directly to the shadow set (also known as the virtual unit), as shown in Figure 7-1.

Figure 7-1 Application Writes to a Shadow Set

If you specify the minicopy qualifier (/POLICY=MINICOPY[=OPTIONAL]) when you dismount a shadow set member, a write bitmap is created. Subsequent writes to the shadow set are recorded by the write bitmap. Note that the write bitmap records only the logical block numbers (LBNs) of the associated writes, not the contents. The address is noted by setting one or more bits in a write bitmap; each bit corresponds to a range of 127 disk blocks.

When data is written to any block in the range of 127 blocks, the bit in the write bitmap that corresponds to that range is set. After the bit or bits are set, the data is written to the shadow set, as shown in Figure 7-2.

Figure 7-2 Application Writes to a Write Bitmap

When the member is returned to the shadow set, the write bitmap is used to direct the minicopy operation, as shown in Figure 7-3. While the minicopy operation is taking place, the application continues to read and write to the shadow set.

Figure 7-3 Member Returned to the Shadow Set (Virtual Unit)

With the minicopy function, a full copy is no longer required when a member is returned to its shadow set, provided that the system managers follow the guidelines provided in Section 7.12. Note that, in this chapter, copy and full copy mean the same thing.

Several DCL commands can be used to manage write bitmaps. System parameters are provided for managing the write bitmap updates in an OpenVMS Cluster system and for setting an upper limit on shadow sets per node.

7.2 Different Uses for Copy and Minicopy

Prior to the introduction of minicopy, the copy operation was used for two purposes: to add members to a virtual unit, and to restore a member to the shadow set from which it was removed. In order for a member to rejoin the shadow set, its data must be made to match the data on the shadow set.

The copy operation remains the only method for creating a multiple member shadow set. The minicopy operation is now the preferred method for returning a member to a shadow set.

Typically, the reason for removing a shadow set member is to back up the data onto tape or disk.

To use a shadow set member to perform a backup operation, a system manager must perform the following steps:

• Using the SHOW DEVICE command, verify that the virtual unit is not marked for a merge operation.
• Stop the application I/O
  The method for doing this is specific to the application and the computing environment.
• Remove a shadow set member
• Reactivate the application
• Back up the data of the shadow set member to disk or tape
  While the backup is progressing, the application is writing data to the remaining members of the shadow set.
• Return the shadow set member to the shadow set when the backup is complete.

The minicopy operation can be used at the discretion of the system manager and at a time chosen by the system manager.

Because minicopy can significantly reduce the time it takes to return a member to a shadow set, it gives system managers greater flexibility in scheduling the removal and return of a shadow set member, and it improves availability.

The time needed to perform a minicopy is proportional to the amount of change that occurred to a shadow set in the disk's absence. A shorter copy time gives sites more flexibility in managing backups.

Table 7-1 shows the results from one series of tests, comparing full copy and minicopy times for shadow sets over a spectrum of write activity. The results presented in Table 7-1 and Table 7-2 should be used only as an indication of the performance gain you may experience using minicopy.

Table 7-1 Comparison of Minicopy and Full Copy Performance

Percentage of Bits Set	Time for Full Copy (seconds)	Time for Minicopy (seconds)	Minicopy Time as Percentage of Full Copy Time
100%	4196.09	3540.21	84.4%
90%	3881.95	3175.92	81.8%
80%	3480.50	2830.47	81.3%
75%	3290.67	2614.87	79.5%
70%	3194.05	2414.03	75.6%
60%	2809.06	2196.60	78.2%
50%	2448.39	1759.67	71.9%
40%	2076.52	1443.44	69.5%
30%	1691.51	1039.90	61.5%
25%	1545.94	775.35	50.2%
20%	1401.21	682.67	48.7%
15%	1198.80	554.06	46.2%
10%	1044.33	345.78	33.1%
5%	905.88	196.32	21.7%
2%	712.77	82.79	11.6%
1%	695.83	44.90	6.5%

Table 7-2 shows the results from another series of tests, comparing performance times of a hardware assisted copy (using MSCP disk copy data (DCD) commands on an HSJ controller) with a minicopy over a spectrum of write activity.

Table 7-2 Comparison of Minicopy and Hardware-Assist (DCD) Copy Performance

Percentage of Bits Set	DCD Copy Time (seconds)	Minicopy Time (seconds)	Minicopy Time as Percentage of DCD Copy Time
100%	1192.18	1181.61	99.1%
90%	1192.18	1097.03	92.0%
80%	1192.18	979.06	82.1%
70%	1192.18	862.66	72.4%
60%	1192.18	724.61	60.8%
50%	1192.18	627.24	52.6%
40%	1192.18	490.70	41.2%
30%	1192.18	384.45	32.3%
20%	1192.18	251.53	21.1%
10%	1192.18	128.11	10.7%
5%	1192.18	71.00	6.0%
0%	1192.18	8.32	0.7%

7.4 Procedure for Using Minicopy

To use the minicopy operation:

1. Start a write bitmap.
   A write bitmap is started by specifying the new qualifier /POLICY=MINICOPY[=OPTIONAL] to the DISMOUNT command when removing a member from a shadow set. You can also start a write bitmap with the MOUNT command when mounting a shadow set less one or two members, as described in Section 7.6.2.
2. Use the write bitmap for a minicopy operation when you return the shadow set member to the shadow set.
   If a write bitmap exists for the shadow set, a minicopy operation is invoked by default by the following MOUNT command:

   $ MOUNT DSA42/SHAD=$4$DUA42 volume-label

   
   To guarantee that only a minicopy takes place, use the /POLICY=MINICOPY qualifier, as shown in the following example:

   $ MOUNT DSA42/SHAD=$4$DUA42 volume-label/POLICY=MINICOPY

   
   If a write bitmap does not exist for a minicopy, the mount fails.
   When a minicopy operation is completed, the write bitmap associated with the disk is deleted.

For a detailed description of how to use /POLICY=MINICOPY[=OPTIONAL] with the MOUNT and DISMOUNT commands, see Section 7.6 and Section 7.7.

7.5 Minicopy Restrictions

The following restrictions apply to the use of minicopy:

• Minicopy can be used in an OpenVMS Cluster only when all nodes in the cluster are running either OpenVMS Alpha Version 7.2--2 or OpenVMS Version 7.3 (or later), or a combination of these versions. OpenVMS VAX Version 7.3 can support and contribute to the bitmap that is mastered by an OpenVMS Alpha node. If you attempt to use earlier versions of OpenVMS in the cluster, the minicopy feature is disabled.
• The write bitmap can be used only once.
  For example, if you dismount a three-member shadow set consisting of D1, D2, and D3, and you then mount only D1 with the /POLICY=MINICOPY[=OPTIONAL] qualifier, a write bitmap is created. When you mount either D2 or D3 back into the shadow set, a minicopy is performed. When you mount the remaining member into the shadow set, a full copy is performed.
  To avoid the requirement of a full copy on the second member, dismount shadow set members one at a time, using /POLICY=MINICOPY for each. In that way, you will have a write bitmap for each shadow set member. When you return each disk to the shadow set, you will be able to do a minicopy for each.
• You cannot prioritize which member is updated by a minicopy operation if you specify two members in the same MOUNT command.
  To ensure that the minicopy occurs immediately, specify only one shadow set member in each MOUNT command. Wait for the minicopy to start, then add the next member with another MOUNT command.
• If a shadow set is already marked by the volume shadowing software for a merge operation, the merge operation occurs, and a write bitmap is not created.
• Unused write bitmaps for a virtual unit remain in memory when the virtual unit is dismounted. When the virtual unit is mounted again, they are automatically deleted.
  You can delete excess write bitmaps with the DELETE command, as described in Section 7.10.4.
• Misleading error message
  When you attempt to start a write bitmap and dismount a shadow set member (with DISMOUNT/POLICY=MINICOPY[=OPTIONAL]), the following error message is displayed if the shadow set member is in a merge operation or is a copy target:

  %DISM-F-SRCMEM, only source member of shadow set cannot be dismounted

  
  A more meaningful error message is planned for a future version of minicopy.

• If a node with one or more master bitmaps shuts down or crashes, the bitmaps on the node are deleted. Therefore, the shadow sets whose master bitmaps were deleted will not be able to use a minicopy operation. Instead, a full copy will be performed.
• If a shadow set member leaves the set because of an error or timeout, a write bitmap will not be available. A write bitmap is only available for a minicopy when a shadow set member is explicitly dismounted.
• If you intend to use the minicopy feature in a mixed-architecture OpenVMS Cluster system, Compaq advises you to set the SHADOW_MAX_COPY system parameter to zero on all VAX systems. This setting prevents a copy from being performed on a VAX when the intent was to perform a minicopy on an Alpha. In a mixed-architecture cluster, it is possible, although highly unlikely, that a VAX system could be assigned the task of adding a member to a shadow set. Because a VAX system cannot perform a minicopy, it would perform a full copy instead. Fo information about SHADOW_MAX_COPY, see Section 3.2.
• Additional steps are required to access the dump file from a system disk shadow set in which a minicopy operation was used to return a member to the shadow set. For more information, see Section 1.4.2.1.

The DCL commands DISMOUNT and MOUNT are used for creating write bitmaps. The MOUNT command is used for starting a minicopy operation using a write bitmap (see Section 7.7).

7.6.1 Creating a Write Bitmap With DISMOUNT

To create a write bitmap, you must specify the /POLICY=MINICOPY[=OPTIONAL] qualifier with the DISMOUNT command. If you specify /POLICY=MINICOPY=OPTIONAL, a write bitmap is created if there is sufficient memory. The disk is dismounted, regardless of whether a write bitmap is created.

The following example shows the use of the POLICY=MINICOPY=OPTIONAL qualifier with the DISMOUNT command:

$ DISMOUNT $4$DUA1 /POLICY=MINICOPY=OPTIONAL

This command removes $4$DUA1 from the shadow set and starts logging writes to a write bitmap, if possible.

If you specify /POLICY=MINICOPY only (that is, if you omit =OPTIONAL) and there is not enough memory on the node to create a write bitmap, the dismount fails.

7.6.2 Creating a Write Bitmap With MOUNT

You can create a write bitmap with the MOUNT command under the following conditions:

• The shadow set that was previously mounted was correctly dismounted.
  A multiple member shadow set must have been mounted before on the same node, on another node in the same cluster, or on another node outside the cluster.
• The shadow set is not currently mounted on any other node in the cluster (if the node on which you are mounting the shadow set is in a cluster).
• When you mount the shadow set, you mount it minus one member.
• You specify the /POLICY=MINICOPY[=OPTIONAL] qualifier to the MOUNT command.

The write bitmap created with this command is used for a minicopy operation when you later mount one of the former members of the shadow set into the set.

If you specify the /POLICY=MINICOPY=OPTIONAL qualifier and the shadow set is already mounted on another node in the cluster, the MOUNT command succeeds but a write bitmap is not created.

7.7 Starting a Minicopy Operation

If a write bitmap exists for a shadow set member, a minicopy operation starts by default when you specify the MOUNT command to return a shadow set member to the shadow set. This is equivalent to using the /POLICY=MINICOPY=OPTIONAL qualifier to the MOUNT command. If a write bitmap is not available, a full copy occurs.

An example of using the /POLICY=MINICOPY=OPTIONAL qualifier with the MOUNT command follows:

$ MOUNT DSA5/SHAD=$4$DUA0/POLICY=MINICOPY=OPTIONAL volume_label

If the shadow set (DSA5) is already mounted and a write bitmap exists for this shadow set member ($4$DUA0), the command adds the device $4$DUA0 to the shadow set with a minicopy operation. If a write bitmap is not available, this command adds $4$DUA0 with a full copy.

To ensure that a MOUNT command succeeds only if a minicopy can take place, specify /POLICY=MINICOPY only (that is, omit =OPTIONAL). If a write bitmap is not available, the mount will fail.

7.8 Master and Local Write Bitmaps

In an OpenVMS Cluster system, a master write bitmap is created on the node that issues the DISMOUNT or MOUNT command that creates the write bitmap. When a master write bitmap is created, a local write bitmap is automatically created on all other nodes in the cluster on which the shadow set is mounted, provided the nodes have sufficient memory.

A master write bitmap contains a record of all the writes to the shadow set from every node in the cluster that has the shadow set mounted. A local write bitmap tracks all the writes that the local node issues to a shadow set.

Note that if a node with a local bitmap writes to the same logical block number (LBN) of a shadow set more than once, only the LBN of the first write is sent to the master write bitmap. The minicopy operation uses the LBN for the update, not the number of changes to the same LBN.

When there is not enough memory on a node to create a local write bitmap, the node sends a message for each write directly to the master write bitmap. This will degrade application write performance.

7.9 System Parameters for Managing Write Bitmap Messages and Shadow Set Limit

System parameters are available for managing the update traffic between a master write bitmap and its corresponding local write bitmaps in an OpenVMS Cluster system. Another new system parameter controls whether write bitmap system messages are sent to the operator console and if they are to be sent, the volume of messages. These system parameters are dynamic, that is, they can be changed on a running system. They are shown in Table 3-3.

In addition, a new volume shadowing system parameter, SHADOW_MAX_UNIT, is provided for specifying the maximum number of shadow sets that can exist on a node. This parameter is described in Table 3-1.

The system parameters for managing write bitmap message traffic control whether the messages are buffered and then packaged in a single SCS message to update the master write bitmap or whether each one is sent immediately. The system parameters are used to set the upper and lower threshholds of message traffic and a time interval during which the traffic is measured.

The writes issued by each remote node are, by default, sent one by one in individual SCS messages to the node with the master write bitmap. This is known as single-message mode.

If the writes sent by a remote node reach an upper threshhold of messages during a specified interval, single-message mode switches to buffered-message mode. In buffered-message mode, the messages (up to nine) are collected for a specified interval and then sent in one SCS message. During periods of increased message traffic, grouping multiple messages to send in one SCS message to the master write bitmap is generally more efficient than sending each message separately.

	privacy and legal statement
5423PRO_010.HTML