2.1 Driver Features
| | |
| ||
| ||
Disk drivers provide the following features:
Multiple controllers of the same type (except RB730), for example, more than one MBA or RK611 can be used on the system
Multiple disk drives per controller (the exact number depends on the controller)
Different types of disk drives on a single controller
Static dual porting (MBA drives only)
Overlapped seeks (except RL02, RX01, RX02, and TU58)
Data checks on a per-request, per-file, or per-volume basis (except RX01 and RX02)
Full recovery from power failure for online disk drives with volumes mounted
Extensive error recovery algorithms, such as error code correction and offset (except RB02, RL02, RX01, RX02, and TU58); for DSA disks, these algorithms are implemented in the controller
Dynamic, as well as static, bad block handling
Logging of device errors in a file that can be displayed by field service personnel or customer personnel
Online diagnostic support for drive level diagnostics
Multiple-block, noncontiguous, virtual I/O operations at the driver level
Logical-to-physical sector translation (RX01 and RX02 only)
The following sections describe these features in greater detail.
A data check is made after successful completion of a read or write operation and, except for the TU58, compares the data in memory with the data on disk to make sure they match.
Disk drivers support data checks at the following levels:
Per volume—You can specify the characteristics “data check all reads” and “data check all writes” when the volume is mounted. The HP OpenVMS DCL Dictionary describes volume mounting and dismounting. The HP OpenVMS System Services Reference Manual describes the Mount Volume ($MOUNT) and Dismount Volume ($DISMOUNT) system services.
Per file—You can specify the file access attributes “data check on read” and “data check on write.” File access attributes are specified when the file is accessed. Chapter 1 of this manual and the OpenVMS Record Management Services Reference Manual describe file access.
Offset recovery is performed during a data check, but error code correction (ECC) is not performed (see “Error Recovery”). For example, if a read operation is performed and an ECC correction is applied, the data check would fail even though the data in memory is correct. In this case, the driver returns a status code indicating that the operation was completed successfully, but the data check could not be performed because of an ECC correction.
Data checks on read operations are extremely rare, and you can either accept the data as is, treat the ECC correction as an error, or accept the data but immediately move it to another area on the disk volume.
A data check operation directed to a TU58 does not compare the data in memory with the data on tape. Instead, either a read check or a write check operation is performed (see “Read” and “Write”).
The operating system ensures that when an I/O write operation returns a successful completion status, the data is available on the disk or tape media. Applications that must guarantee the successful completion of a write operation can verify that the data is on the media by specifying the data check function modifier IO$M_DATACHECK. Note that the IO$M_DATACHECK data check function, which compares the data in memory with the data on disk, affects performance because the function incurs the overhead of an additional read operation to the media.
If a system failure occurs while a multiple-block write operation is in progress, the operating system does not guarantee the successful completion of the write operation. (OpenVMS does guarantee single-block write operations to DSA drives.) When a failure interrupts a write operation, the data may be left in any one of the following conditions:
The new data is written completely to the disk blocks on the media, but a completion status was not returned before the failure.
The new data is partially written to the media so that some of the disk blocks involved in the I/O contain the data from the write operation in progress, and the remainder of the blocks contain the data that was present before the write operation.
The new data was never written to the disk blocks on the media.
To guarantee that a write operation either finishes successfully or (in the event of failure) is redone or rolled back as if it were never started, use additional techniques to ensure data correctness and recovery. For example, using database journaling and recovery techniques allows applications to recover automatically from failures such as the following:
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 or controller failure or a failure of node-to-node communications.
Failure of a CPU (such as a system failure, system halt, power failure, or system shutdown) during a multiple-block write operation.
Mistaken deletion of a file.
Corruption of file system pointers.
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.
Error recovery in the operating system is aimed at performing all possible operations to complete an I/O operation successfully. Error recovery operations fall into the following categories:
Handling special conditions such as power failure and interrupt timeout.
Retrying nonfatal controller and drive errors. For DSA and SCSI disks, this function is implemented by the controller.
Applying error correction information (not applicable for RB02, RL02, RX01, RX02, and TU58 drives). For DSA and SCSI disks, error correction is implemented by the controller.
Offsetting read heads to try to obtain a stronger recorded signal (not applicable for RB02, RL02, RB80, RM80, RX01, RX02, and TU58 drives). For DSA and SCSI disks, this function is implemented by the controller.
The error recovery algorithm uses a combination of these four types of error recovery operations to complete an I/O operation:
Power failure recovery consists of waiting for mounted drives to spin up and come on line, followed by reexecution of the I/O operation that was in progress at the time of the power failure.
Device timeout is treated as a nonfatal error. The operation that was in progress when the timeout occurred is reexecuted up to eight times before a timeout error is returned.
Nonfatal controller/drive errors are executed up to eight times before a fatal error is returned.
All normal error recovery procedures (nonspecial conditions) can be inhibited by specifying the inhibit retry function modifier (IO$M_INHRETRY). If any error occurs and this modifier is specified, the virtual, logical, or physical I/O operation is immediately terminated, and a failure status is returned. This modifier has no effect on power recovery and timeout recovery.
Although SCSI disks do not conform to DSA, they do support the following error recovery features:
Static and dynamic bad block replacement (BBR)
Error correction code (ECC)
Reexecution of read or write operations within the SCSI drive
Reexecution of read or write operations by the SCSI disk class driver
All SCSI disks supplied by HP implement the REASSIGN BLOCKS command, which relocates data for a specific logical block to a different physical location on the disk. The SCSI disk class driver reassigns the block in the following instances: (1) when the retry threshold is exceeded during an attempt to read or write a block of data on the disk or (2) when an irrecoverable error occurs during a write operation.
Unlike DSA, there is no forced error flag in SCSI. Blocks that produce irrecoverable errors during read operations are not reassigned in order to prevent undetected loss of user data. Instead, the SCSI disk class driver returns the SS$_PARITY status whenever a read operation results in an irrecoverable error.
The operating system provides audio functionality through the SCSI disk class driver. The SCSI disk class driver provides an interface by which the audio commands can be issued to SCSI devices. These commands can be issued through the QIO function call. This functionality is available for devices, such as CD-ROMs that have audio capability.
The IO$_AUDIO function code allows the SCSI disk class driver to process the SCSI audio commands. An Audio Control Block (AUCB) must be defined for a specific SCSI audio command. This AUCB provides the SCSI disk class driver with command-specific arguments and control information. An application program must use the IO$_AUDIO function code and provide the AUCB for the SCSI driver to process the audio commands.
For more information, see $QIO Interface to Audio Functionality of the SCSI Disk Class Driver.