7.3 Driver Functions
| | |
| ||
| ||
This section describes the major virtual unit functions supported by SHDRIVER. In addition to the virtual unit functions described in this section, SHDRIVER supports all OpenVMS disk functions. SHDRIVER receives QIO operations from application programs and is a client of the disk class drivers DUDRIVER. Applications access the shadow set as they would access a standard OpenVMS disk.
Table 7-1 summarizes the major SHDRIVER functions.
Table 7-1 Functions of the Shadow Set Virtual Unit Driver
| Function | Description |
|---|---|
MOUNTSHAD | Creates a virtual unit |
ADDSHADMBR | Evaluates a physical member and adds members |
COPYSHAD | Triggers and controls copy operations |
REMSHADMBR | Removes a physical member |
AVAILABLE | Virtual unit dissolution |
SENSECHAR | Verifies shadow set status |
READ | Directs I/O to a physical member |
WRITE | Propagates a write operation to all physical members |
SETCHAR | Sets characteristics of the shadow set |
With minor changes, the read and write functions for SHDRIVER operate the same as for the disk class driver (see “Read” and “Write”).
During an SHDRIVER read operation, the host directs the read to the member volume, which will likely return the data the fastest. See the Volume Shadowing for OpenVMS manual for more information about controlling this behavior.
During a write operation, SHDRIVER directs the write to each member volume. The write operations for each member volume usually proceed in parallel; the virtual unit write operation terminates when all writes have completed. The write function for SHDRIVER takes the IO$M_VUEX_FC function modifier; this modifier should not be used by application programs.
The read and write SHDRIVER functions, as well as all user functions, are issued by user programs. All other SHDRIVER functions are invoked by MOUNT and DISMOUNT commands, or the $MOUNT and $DISMOUNT system services.
Remember that volume shadowing provides data availability by protecting against hardware problems or communication path problems that might cause a disk volume to be a single point of failure. If a write request is made to a shadow set, but the system fails before a completion status is returned from all of the shadow set members, it is possible that:
All members might contain the new data.
All members might contain the old data.
Some members might contain new data and others might contain old data.
When the system recovers, volume shadowing performs a merge operation to ensure that the corresponding blocks on each shadow set member contain the same data (right or wrong); therefore, the goal here is not one of data correctness but of data availability. Volume shadowing is designed to make the data on all disks identical, then, if necessary, incorrect data can be reconciled either by the user reentering the data or by an application automatically employing database or journaling techniques.
For example, when used with volume shadowing, OpenVMS RMS journaling allows you to develop applications that can automatically recover from failures such as:
Permanent loss of the path between a CPU data buffer containing the data being written and the disk being written to during a multiple block I/O operation. Communication path loss can occur due to node failure or a failure of node-to-node communications.
Failure of a CPU (such as a system crash, halt, power failure, or system shutdown) during a multiple block write I/O operation.
Mistaken deletion of a file.
Corruption of file system pointers.
OpenVMS RMS file corruption due to a software error or incomplete bucket write operation to an indexed file.
Cancellation of an in-progress multiple block write operation.
For more information about shadowing merge operations, see the Volume Shadowing for OpenVMS manual.