|
|
The SVR5 SDI 4 mass storage I/O multi-layered architecture is an evolution of the two-layer architecture used in SCO SVR5 2.0.
In SDI versions prior to SDI 4, the I/O stack contained two layers populated by two general classes of drivers: controller-specific drivers (the HBA driver class) and device-specific drivers (the target driver class).
Beginning with SDI 4, multiple driver instances of a new class of drivers (called ``layered'' drivers) can be placed into the mass storage I/O stack in the path of the I/O operation. This resembles the streams model for networking stacks.
Mass storage I/O multi-layered architecture
SDI is the infrastructure that brings all the drivers together. Drivers do not communicate directly, all interactions happen through SDI. By shielding a driver from direct knowledge of which driver is above or below it, SDI allows, in theory, arbitrary driver configurations and substitutions.
SDI is based on the SCSI standard, but has been expanded to also support non-SCSI devices. The enhancements to SDI 4 and the SVR5 I/O stack provide the flexibility required to accomodate new technologies such as ccNUMA architectures, multiported devices, and high availability configurations such as multipath I/O (MPIO).
SDI supplements the DDI to organize and simplify the complexity of mass storage device drivers.
SDI is documented in the following manual page sections:
The ``Version applicability'' field on each manual page identifies the SDI versions where each entry point, function, or structure can be used and whether it is used for HBA, target, or layered drivers.
A full set of test suites for SDI drivers are provided to assist in testing and certifying the drivers and the associated hardware. See hbacert and ``Testing and debugging HBA drivers'' for more information.
The SVR5 I/O stack is a multi-layered stack, with three general classes of drivers possible on the stack:
A typical I/O operation will have one target driver, one HBA driver, and zero or more layered drivers on the stack. Each of these classes is discussed below.
A target driver implements the generic abstraction for a type of storage device and deals with the device-specific aspects of the hardware.
For example, the sd01 disk target driver understands how to perform read, write, and open operations on a disk device. It also generates the partition table and the alternate sector table for a disk.
As another example, the st01 tape target driver implements abstractions such as the following:
The set of SDI target drivers supported in SVR5 follows the SCSI-2 model, although, it does not have a target driver for every device type defined in the SCSI standard. The following devices are included:
HBA drivers handle the controller-specific aspects of operating a device. Thus, to read a given block of data on one of the slices on the hard disk, the vtoc driver determines which absolute block on the disk will be read, the target driver passes the read request to the HBA, the HBA driver programs the controller card, issues the read request to the disk and responds to the interrupt generated by the read request. The results of the read operation, whether successful or not, are passed back to the target driver, which then signals the completion of the operation (or handles the error).
Layered drivers, like target drivers, receive operating system buffers as input, but unlike target drivers, they produce modified operating system buffers as output. This allows for arbitrary stacks to be built as they are for STREAMS device drivers. New layers can be inserted as new functionality is required.
SVR5 includes 3 layered drivers:
The fdisk table gives the first level of division called a partition. This is a data structure common to all Intel architectures that resides on the first block of the disk. In conjunction with the system BIOS it allows multiple bootable partitions that are commonly used for different operating systems on the same machine.
The next level of division is the UnixWare slicing, and as it name implies, it is particular to UnixWare. It happens within a disk partition. This allows the system to subdivide in at most 184 slices the active fdisk partition. The slices can later be used to create filesystems or used directly by applications as raw slices such as databases. The vtoc table implements this abstraction. It is saved on the 29 block of the active fdisk partition.
The population of the vtoc table (and the pdinfo structure) used to be part of the sd01 driver in SCO SVR5 2.0. The rework into two independent drivers has substantially simplified and reduced the size of the sd01 driver in SVR5.
The SDI connection module handles communication between the layers of the I/O stack. It provides a defined set of interfaces that allow target drivers to issue commands to HBA drivers, and to enable HBA drivers to respond to target driver requests. Thus, SDI is somewhat like a multiplexor between the layers.
SDI also serves as a router to deliver target driver requests from the various types of target drivers to the correct HBA driver, and HBA driver responses to the correct target driver.
From the operating system perspective, target drivers translate the I/O operations (such as open and close the device, start and stop the I/O operation) to lower level SCSI-like operations. In driver parlance, these operations correspond to driver entry points.
Tracing the flow of an I/O operation through the I/O stack clarifies the relationship of the various layers.
Notice that the level of abstraction for an sb is that of a command or packet that will be transmitted through the SCSI bus without discriminating on its semantics.