RAID, I2O, and NT: Making the Synergy Happen
By Brian A. Berg
Berg Software Design
The next generation of high-performance I/Os is coming to Wintel platforms by way of I2O, or Intelligent I/O. I2O provides an I/O device-driver architecture that is independent of the type of device being controlled and the host operating system. However, I2O will have the greatest effect on the Windows NT market.
Because I2O is built around the Intel i960 processor, the Wintel juggernaut will gain even more steam as the technology matures in 1998. The use of a powerful dedicated processor allows I2O to help break the traditional I/O bottleneck, and it does this best when teamed with a RAID subsystem.
Just as the SCSI devices used in early RAID products had more intelligence than their predecessors (which depended on controllers that resided in the host), higher RAID performance was realized by embedding RAID algorithms in a box external to the host.
With the speed available from the PCI bus, very high data rates can be realized by feeding and reading RAID data to and from this bus. This architecture, commonly called PCI-RAID, is used in a number of boards on the market today. These boards typically include one to three SCSI buses that can be populated with disk drives to form one or more RAID data sets.
How I2O fits in
The higher performance PCI-RAID boards offload the management of the RAID algorithms and the SCSI buses with a dedicated on-board processor. I2O represents the latest evolution of this architecture with its special i960 processor, which has its own realtime operating system (RTOS) to manage subsystem peripherals. These peripherals are managed by intermediate service modules (ISMs) for each device type. RAID is just one of the device types in the I2O framework.
The SCSI controller chip(s) that runs the drive-populated SCSI bus(es) uses a hardware device module (HDM). This module keeps the SCSI HDM interface to the RAID ISM generic. The exclusive OR (XOR) operations required for RAID parity are managed by an XOR HDM. Because XOR hardware is a RAID design option, the XOR HDM may perform the XOR operations itself or it may command XOR hardware to do this work. The fact that an HDM can also be used to emulate XOR chips can ease the chore of system testing during the development phase.
ISMs can be considered to be application programs that run under the RTOS, and they have no hardware-specific dependencies. HDMs can be considered to be device drivers under the RTOS, and they are created for specific hardware products.
PCI-RAID vendors provide the RAID ISM; SCSI chip vendors provide the SCSI HDM; and XOR chip vendors provide XOR HDM. Some RAID vendors are implementing all XOR support directly in their RAID ISM, whether or not their systems include XOR hardware.
For more information . . .
Intel and Microsoft recently Guide Version 1.0 for Microsoft Windows NT Server" document (www.microsoft.com/hwdev/serverdg.htm). A number of industry leaders also contributed to this guide, and it is an essential document for anyone designing servers, add-on cards, and peripherals that are intended to run under Windows NT 5.0. If I2O is implemented in a system, it must meet the requirements defined in this guide and in the I2O Architecture Specification, Version 1.5 or higher. The latter document is available from the I2O Special Interest Group (SIG) at www.i2osig.org. Additional information is available from the RAID Advisory Board at www.raid-advisory.com.
The I2O split driver model consists of two parts: the operating system services module (OSM), which resides on and interfaces to the host operating system, and the hardware device module (HDM), which resides on and interfaces with the adapter to be managed by the driver.
In the I2O software architecture, when the OSM is presented with a request from the host operating system, it translates the request into an I2O message and dispatches it to the appropriate HDM for processing. Upon completion of the request, the HDM dispatches the result back to the OSM by sending a message through the I2O message layer. To the host operating system, the OSM appears just like any other device driver.
Brian A. Berg is president of Berg Software Design, a software consultancy in Saratoga, CA, that specializes in SCSI and storage. He can be reached at email@example.com.