Rebooting a Node
The configuration information of a shadow volume is not saved on the private slice but managed in the memory. For this reason, the shadow volume configuration definitions are cleared when the node on which the shadow volume is defined is rebooted. However, the device special file remains. If such a device special file is left not deleted, issues as described below may occur.
Before intentional shutdowns, it is recommended to remove shadow volumes. If a shadow volume is removed with the sdxshadowvolume -R command, the device special file is also deleted. For details on the sdxshadowvolume -R command, see "D.17 sdxshadowvolume - Shadow volume operations."
When a node is shut down leaving the relevant shadow volume not removed, or if a node on which a shadow volume is defined is rebooted unexpectedly because of an event such as a panic and a power cutoff, the device special file for the shadow volume must be deleted in the following procedure.
[Procedure]
Check the system for existing classes.
In the following example, there are RootClass, Class1, and Class2.
# sdxinfo -C |
Find the directories containing the device special files of classes.
In the following example, RootClass, Class1, and Class2 are the directories for the device special files of those existing classes, and _adm and _diag are the special files used by GDS. Class3, other than those directories, is the directory for the device special file of the extinct shadow class.
# cd /dev/sfdsk |
Delete the directory for the device special file of the extinct shadow class.
# rm -r Class3 |
Even if the device special file of an extinct shadow volume remains, no problem will arise if a shadow volume in the same configuration, of the same class name, and with the same volume name is re-created.
Otherwise, the following issues will occur. If a logical volume or a shadow volume is created in the situation that the device special file, /dev/sfdsk/Shadow_Class_Name/[r]dsk/Shadow_Volume_Name, of an extinct shadow volume remains, the minor number of the created volume may become the same as the minor number of /dev/sfdsk/Shadow_Class_Name/[r]dsk/Shadow_Volume_Name. In this situation, if /dev/sfdsk/Shadow_Class_Name/[r]dsk/Shadow_Volume_Name is accessed without recognition of extinction of the shadow volume, the newly created volume is accessed, and it can cause an application error and corruption of data on the newly created volume.
Accessing a Shadow Volume
Shadow volumes and the corresponding logical volumes are managed independently. For example, the change of the slice status in one volume is not updated in the slice status in the other volume. For this reason, you must note the following operational particulars when using shadow volumes.
When a shadow volume is created in another domain (domain beta) for the disk area managed as a mirror volume in a certain domain (domain alpha), the mirror volume in domain alpha and the shadow volume in domain beta cannot be accessed simultaneously. If they are accessed simultaneously, the following issues arise.
If an I/O error occurs in the slice configuring the mirror volume in domain alpha, that slice becomes INVALID and is detached from the mirror volume. However, GDS in domain beta does not detect this I/O error, and consequently the shadow slice is not made INVALID and is not detached from the shadow volume. Here, synchronization of the shadow volume is not ensured.
Likewise, if an I/O error occurs in the shadow slice in domain beta, the slice in the corresponding mirror volume in domain alpha is not made INVALID and is not detached from the mirror volume. Here, synchronization of the mirror volume is not ensured. If an I/O error occurs on the shadow slice, working around, such as swapping the disks and resynchronization copying of the mirror volume, is required in domain alpha.
These particulars apply when the disk area for a mirror volume and a shadow volume are identical. A mirror volume and a shadow volume corresponding to a replica of the mirror volume (a temporarily detached slice, a proxy volume or a copy destination disk area for a disk unit's copy function) can be accessed simultaneously.
When a shadow volume is created in another domain (domain beta) for the disk area managed as a mirror volume in a certain domain (domain alpha) and accessed, the following must be set up for the mirror volume in domain alpha.
Mirror volumes must be inactivated to prevent access to the mirror volume corresponding to the shadow volume.
JRM for volumes must be enabled ("on") for the mirror volume corresponding to the shadow volume.
These settings are necessary for the following reasons.
If a node in domain alpha panics and resynchronization copying is conducted on the mirror volume in domain alpha while the shadow volume is accessed in domain beta, synchronization between the shadow volume and the mirror volume is no longer ensured. Though the settings as above, resynchronization copying is no longer conducted on the mirror volume in domain alpha even if a node in domain alpha panics.
The settings as above are necessary only for a mirror volume created for the disk area identical to the shadow volume's disk area. When a shadow volume corresponding to a replica of a mirror volume (a temporarily detached slice, a proxy volume or a copy destination disk area for a disk unit's copy function) is crated, these settings are not necessary for the copy source mirror volume.
Information
Resynchronization Copying after Panic
Resynchronization copying is not conducted after panic when JRM for volumes is enabled ("on") and that volume is not written in. Resynchronization copying occurs after panic when JRM for volumes is disabled ("off") and that volume is active.
When a slice is temporarily detached from a mirror volume in a certain domain (domain alpha) and data is written from a shadow volume in another domain (domain beta) to the area of this volume or slice, JRM for slices must be disabled ("off") prior to reattaching the slice.
If JRM for slices is enabled ("on"), the following issue arises.
When JRM for slices is enabled ("on"), only the difference between the volume and the slice is copied by reattaching the slice. The difference information for the volume and the slice is managed by JRM for slices in domain alpha. However, JRM for slices in domain alpha does not recognize write events from domain beta, and the difference resulting from data being written from domain beta are not updated in the difference information. The difference resulting from write events from domain beta, therefore, are not copied when the slice is reattached while JRM for slices is "on" in domain alpha. As a result, synchronization of the volume is no longer ensured.
If a proxy volume is parted from the master in a certain domain (domain alpha) and data is written from a shadow volume in another domain (domain beta) to the area of this master or proxy, JRM for proxies must be disabled ("off") prior to rejoining the proxy. In addition, JRM for proxies must be disabled ("off") prior to restoring the master using the proxy.
If JRM for proxies is enabled ("on"), the following issues arise.
When JRM for proxies is enabled ("on"), only the difference between the master and the proxy is copied by rejoining or restoring. The difference information for the master and the proxy is managed by JRM for slices in domain alpha. However, JRM for proxies in domain alpha does not recognize write events from domain beta, and the difference resulting from data being written from domain beta are not updated in the difference information. The difference resulting from write events from domain beta, therefore, are not copied when the proxy is rejoined or the master is restored while JRM for proxies is "on" in domain alpha. As a result, synchronization between the master and the proxy is no longer ensured.
When one of a disk unit's copy function (EC, REC, TimeFinder, and SRDF) with a resynchronization feature based on equivalent copy capability is used for master-to-proxy copy processes, data written from domain beta is also updated in the difference information managed by these disk unit's copy functions. Under these circumstances, JRM for proxies do not have to be disabled ("off") prior to rejoining. Note, however, that JRM for proxies must be disabled ("off") prior to restoring since necessity of synchronization copying is determined based on the difference information managed by JRM for proxies. To ensure the data integrity, it is recommended to disable JRM for proxies prior to rejoining even when a disk unit's copy function is used.
Information
A Copy Function of a Disk Unit with Resynchronization Feature Based on Equivalent Copy
When just resynchronization from a master to a proxy is conducted with one of a disk unit's copy functions (EC, REC, TimeFinder, SRDF) with a resynchronization feature based on equivalent copy capability, this feature is used regardless of whether JRM for proxies is "on" or "off."
Data may be written to a shadow volume even if the operation for writing is not especially intended. For example, executing mount(1M) (excluding when using the -o ro option), fsck(1M), newfs(1M), sfxnewfs(1M), or sfxadm(1M) results in the write operation.
When a proxy is rejoined, a master is restored, or a slice is reattached once a shadow volume is created, it is recommended to disable the just resynchronization mechanism mode (JRM) regardless of whether or not data is written into the shadow volume in order to ensure the data integrity.
