Introduction to the Storage Device Interface (SDI)

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:

• Section D2sdi manual pages Manual pages for all SDI entry point routines plus manual pages that contain SDI-specific information about using DDI entry point routines in SDI HBA, target, and layered drivers.

• Section D3sdi manual pages Manual pages for all SDI kernel functions. SDI drivers use these functions as well as the DDI kernel functions that are documented in Section D2 manual pages.

• Section D4sdi manual pages Manual pages for the SDI kernel structures that drivers access. SDI drivers use these structures as well as the DDI kernel structures that are documented in Section D2 manual pages.

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.

Multi-layered I/O stack

The SVR5 I/O stack is a multi-layered stack, with three general classes of drivers possible on the stack:

• ``Target drivers''

• ``Host Bus Adapter (HBA) drivers''

• ``Layered drivers''

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.

Target drivers

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:

• Opens are exclusive; only one open is performed on the device at a time.

• An open is in either read or write mode, but not both.

• Verify that a tape is available before starting an I/O operation.

• On write operations, lay down a filemark to indicate end of data.

• Rewind the tape (optional).

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:

• Random Access Devices such as disks, named sd01

• Sequential Access devices such as tapes, named st01

• CD-ROMs, called sc01

• Medium Changer, called mc01

• Processor devices

Host Bus Adapter (HBA) drivers

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

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:

vtoc(7)

The vtoc driver implements the abstraction of subdividing large disks into smaller more manageable divisions.

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.

mpio(7)

Supports devices that have multiple physical I/O ``paths'' (sometimes called ``channels'') to it. The mpio driver is in charge of identifying paths that lead to the same storage device. See ``Multipath I/O driver''.

RAID

A RAID driver encapsulates proprietary interfaces to RAID devices. RAID referes to a ``class'' of drivers, with a possible instance for every implementation or model of a RAID device. Theoretically, every hardware RAID vendor would write their own to achieve full operating system support for their features. See ``RAID'' and ``RAID drivers''.

SDI connection module

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.

SDI I/O flow

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.

1. The target driver's entry point routine executes. Usually this entry point maps to a single system call.

2. This generates a data structure known as a SCSI Block (sb(D4sdi)). It contains a SCSI Command Descriptor Block (CDB) which is essentially a SCSI command as defined by the standard, including a buffer where the data for the command is stored and other operational information. An entry point may generate many sb structures during its execution.

   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.

3. SDI acts as a switch through which an sb is routed to the appropiate Host Adapter.

4. An HBA driver takes an sb structure as input to program the proprietary hardware. All operating system resources and information necessary to perform this task are contained within the sb.

   • For SCSI adapters, the SCSI CDB is extracted from the sb and sent on the bus.

   • For non-SCSI adapters, the CDB is translated to an equivalent command. This is the case for the IDE driver: a SCSI read CDB is used to program the register file for the ATA interface to perform a read.

5. When the I/O is completed, the reverse path is travelled. In the hardware, the controller generates an interrupt which calls the HBA driver. Here, the status and results are transfered into the sb. In turn, through the SDI layer, the target driver is called. It is here that the status is analyzed and, according to the command and the type of device, a recovery strategy may be attempted.