Document revision date: 30 March 2001

Example 6-1 shows what happens when you create a shadow set by mounting two disk volumes that have never been a part of a shadow set. Because neither disk volume has been a part of a shadow set, the Mount utility (MOUNT) assumes that the first disk named in the MOUNT command is the source member. When the Mount utility checks the volume labels on the disks, it discovers that they are different from each other, and the utility automatically performs a copy operation.

In this example, DSA0 is the virtual unit name, $1$DUA8 and $1$DUA89 are the names of the disk volumes, and SHADOWDISK is the volume label.

Example 6-1 Copy Operation: Creating a New Shadow Set

$ MOUNT DSA0: /SHADOW=($1$DUA8:,$1$DUA89:) SHADOWDISK %MOUNT-I-MOUNTED, SHADOWDISK mounted on _DSA0: %MOUNT-I-SHDWMEMSUCC, _$1$DUA8: (FUSS) is now a valid member of the shadow set %MOUNT-I-SHDWMEMCOPY, _$1$DUA89: (FUSS) added to the shadow set with a copy operation $ SHOW DEVICE DSA0: Device Device Error Volume Free Trans Mnt Name Status Count Label Blocks Count Cnt DSA0: Mounted 0 SHADOWDISK 890937 1 1 $1$DUA8: (FUSS) ShadowSetMember 0 (member of DSA0:) $1$DUA89: (FUSS) ShadowCopying 0 (copy trgt DSA0: 1% copied)

The SHOW DEVICE display in Example 6-1 shows the shadow set during the copy operation (transient state). Because the SCB information on $1$DUA8 and $1$DUA89 indicates that these devices have never been part of a shadow set, the shadowing software uses the first device named in the command line ($1$DUA8) as the source of the copy operation. The device status "ShadowSetMember" indicates that the $1$DUA8 device is a source shadow set member, and "ShadowCopying" indicates that the physical device $11$DUA89 is the target of a copy operation.

Suppose you want to add a new member to an existing shadow set, and the device you add is a previous member of this same shadow set. In this case, the volume label of the new member matches that of the current shadow set members, but the new member's MOUNT generation number is out of date compared with those of the current members. Thus, the Mount utility automatically performs a copy operation on that member.

Example 6-2 shows the format of the MOUNT command and MOUNT status messages returned when you add the $3$DIA12 device to the shadow set represented by the DSA9999 virtual unit. Notice that you do not need to list the member units currently in the shadow set on the MOUNT command line.

Example 6-2 Copy Operation: Adding a Member to an Existing Shadow Set

$ MOUNT /SYSTEM DSA9999: /SHADOW=$3$DIA12: AXP_SYS_071 %MOUNT-I-MOUNTED, AXP_SYS_071 mounted on _DSA9999: %MOUNT-I-SHDWMEMCOPY, _$3$DIA12: (SHAD03) added to the shadow set with a copy operation $ SHOW DEVICE DSA9999: Device Device Error Volume Free Trans Mnt Name Status Count Label Blocks Count Cnt DSA9999: Mounted 0 AXP_SYS_071 70610 1 1 $3$DIA7: (BGFUSS) ShadowSetMember 0 (member of DSA9999:) $3$DIA5: (SHAD03) ShadowSetMember 0 (member of DSA9999:) $3$DIA12: (SHAD03) ShadowCopying 0 (copy trgt DSA9999: 0% copied)

Example 6-3 shows what happens when a three-member shadow set is dissolved on one node and then is immediately remounted on another node. When the Mount utility checks the volume information on each member, it finds that the volume information is consistent across the shadow set. Thus, a copy operation is not necessary when the shadow set is mounted.

In Example 6-3, DSA10 is the virtual unit and $3$DUA10, $3$DUA11, and $3$DUA12 are the member volumes. The first part of the example displays the output from a SHOW DEVICE command, which shows that the shadow set is mounted and in a steady state. Then the user dismounts the DSA10 shadow set and immediately remounts it.

Example 6-3 No Copy Operation: Rebuilding a Shadow Set

$ SHOW DEVICE D Device Device Error Volume Free Trans Mnt Name Status Count Label Blocks Count Cnt DSA10: Mounted 0 VAX_SYS_071 292971 1 1 $3$DUA10: (MYNODE) ShadowSetMember 0 (member of DSA10:) $3$DUA11: (MYNODE) ShadowSetMember 0 (member of DSA10:) $3$DUA12: (MYNODE) ShadowSetMember 0 (member of DSA10:) $ DISMOUNT /NOUNLOAD DSA10: %%%%%%%%%%% OPCOM 24-MAR-1997 20:26:41.40 %%%%%%%%%%% $3$DUA10: (MYNODE) has been removed from shadow set. %%%%%%%%%%% OPCOM 24-MAR-1997 20:26:41.69 %%%%%%%%%%% $3$DUA11: (MYNODE) has been removed from shadow set. %%%%%%%%%%% OPCOM 24-MAR-1997 20:26:41.69 %%%%%%%%%%% $3$DUA12: (MYNODE) has been removed from shadow set. %%%%%%%%%%% OPCOM 24-MAR-1997 20:26:41.69 %%%%%%%%%%% $ MOUNT /SYSTEM DSA10: /SHADOW=($3$DUA10:, $3$DUA11:, $3$DUA12:) VAX_SYS_071 %MOUNT-I-MOUNTED, VAX_SYS_071 mounted on _DSA10: %MOUNT-I-SHDWMEMSUCC, _$3$DUA10: (MYNODE) is now a valid member of the shadow set %MOUNT-I-SHDWMEMSUCC, _$3$DUA11: (MYNODE) is now a valid member of the shadow set %MOUNT-I-SHDWMEMSUCC, _$3$DUA12: (MYNODE) is now a valid member of the shadow set $

Example 6-4 shows the output from the SHOW DEVICE command at the time of the merge operation.

When a system fails, the volume information is left in a state that shows that each shadow set member was not properly dismounted. If you issue the MOUNT command again after the node reboots, the shadowing software automatically performs a merge operation on the shadow set.

Example 6-4 Merge Operation: Rebuilding a Shadow Set

$ SHOW DEVICE DSA42: Device Device Error Volume Free Trans Mnt Name Status Count Label Blocks Count Cnt DSA42: Mounted 0 ATHRUZ 565997 1 1 $4$DUA2: (MYNODE) ShadowMergeMbr 0 (merging DSA42: 0% merged) $4$DUA42: (YRNODE) ShadowMergeMbr 0 (merging DSA42: 0% merged)

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 OpenVMS Version 7.3 (or later). The exception to this rule is for nodes running OpenVMS Version 7.2-xx for which an upgrade will be made available soon after the release of OpenVMS Version 7.3. The upgrade will contain support for minicopy.
• 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.

	privacy and legal statement
5423PRO_009.HTML