[an error occurred while processing this directive]

HP OpenVMS Systems Documentation

Content starts here

HP OpenVMS Alpha Version 7.3--2 Release Notes


Previous Contents Index

4.26.9 Deleting a Fibre Channel Device from a Controller Pair

V7.3-2

If an existing Fibre Channel device is deleted from a controller pair, the user-supplied device identifier (UDID) is also deleted. If that same UDID later is assigned to a LUN located on another controller pair, and if that device is used as a member of a host-based shadow set, it will be added to the shadow set only on the first system. All other systems with that shadow set mounted will not be able to add that device.

This problem will be fixed in a host-based Volume Shadowing remedial kit for OpenVMS Version 7.3-2. See Section 1.6 for information about how to obtain remedial kits.

4.26.10 ANALYZE/DISK/SHADOW Command Behavior

V7.3-2

When you specify the /SHADOW qualifier (new in OpenVMS Version 7.3-2) with the ANALYZE/DISK_STRUCTURE command, the entire contents of a shadow set or a specified range of blocks in a shadow set are examined for discrepancies.

If a member of the shadow set experiences connectivity problems for any reason, the ANALYZE/DISK_STRUCTURE command displays the error that it received and then returns the user to the DCL prompt.

To correct the connectivity problem and run the utility again on the same shadow set, you might need to create a temporary file on the virtual unit before reissuing the ANALYZE/DISK/SHADOW command.

Additionally, this utility may report explainable discrepancies between the shadow set members if the shadow set has not undergone a full merge since the shadow set was created. This happens if the shadow set was created using the DCL command INITIALIZE/SHADOW without the /ERASE qualifier and if the disk devices had different contents. It is important to realize that this is not disk corruption. The blocks that are reported as different have not been written to, but they may contain stale data; the blocks reported as inconsistent may even be allocated to a file because there may be unwritten space between the file's end-of-data location and the end of the allocated space.

You can eliminate such inconsistencies by performing a full merge. To initiate a full merge, execute the DCL command SET SHADOW/DEMAND_MERGE DSAxxx. If the devices are served by controllers that support controller-based minimerge (for example, HSJ50s), this command should be issued while the shadow set is mounted on only one node within the cluster. Otherwise, a minimerge will occur, and the discrepancy may not be resolved. When you are adding members to a single member shadow set, a full copy operation will also ensure that the disk is consistent both within and outside of the file system.

If errors are reported on an ANALYZE/DISK/SHADOW command after a full merge has been executed, they should be investigated.

Also see Section 4.26.11 for another note about ANALYZE/DISK/SHADOW command behavior.

4.26.11 ANALYZE/DISK/SHADOW Command Behavior with Dissimilar Device Shadow Sets

V7.3-2

An ANALYZE/DISK/SHADOW command may also report explainable discrepancies if a full merge has not occurred since the shadow set was logically expanded after a new member was added. The following example illustrates this problem:

  • Shadow set DSA1: consists of two members:
    $1$DGA20: (18 GB)
    $1$DGA21: (36 GB)
  • A second 36-GB member, $1$DGA22:, is added to the shadow set with a full copy operation.
  • After the copy completes, $1$DGA20: is removed from the shadow set.
  • At this point, if the SET VOLUME/SIZE DSA1: command is executed, the shadow set virtual unit DSA1: will increase to 36 GB. Then, ANALYZE/DISK/SHADOW will report discrepancies because only the first 18 GB of the shadow set contents were copied to $1$DGA22:.

The discrepancies reported by ANALYZE/DISK/SHADOW are harmless because the space in question has not yet been written by applications.

Also see Section 4.26.10 for another note about ANALYZE/DISK/SHADOW command behavior.

4.26.12 Dismount of Shadow Set Member Using /MINICOPY

V7.3

In an OpenVMS Cluster configuration, if you issue a DISMOUNT command with the /MINICOPY qualifier from a client system to dismount a shadow set member, the command might fail.

Workaround

If the first DISMOUNT command fails, repeat the command, as shown in the following example:


$ SHOW DEVICE DSA5555
Device                  Device           Error    Volume         Free  Trans Mnt
 Name                   Status           Count     Label        Blocks Count Cnt
DSA5555:                Mounted              0  $80$DKA107:    7994646     1  18
$80$DKA107:    (WILD3)  ShadowSetMember      0  (member of DSA5555:)
$80$DKA302:    (WILD3)  ShadowSetMember      0  (member of DSA5555:)
$80$DKA303:    (WILD3)  ShadowSetMember      0  (member of DSA5555:)
$
$
$ DISMOUNT/POLICY=MINICOPY $80$DKA302:
%DISM-W-CANNOTDMT, $80$DKA302: cannot be dismounted
%DISM-F-SRCMEM, only source member of shadow set cannot be dismounted
$
$
$ DISMOUNT/POLICY=MINICOPY $80$DKA302:
$

This problem will be corrected in a future release.


Previous Next Contents Index