Anatomy of the Linux SCSI Subsystem__linux

http://www.ibm.com/developerworks/linux/library/l-scsi-subsystem/

Gnu/linux and SCSI are a natural pair because they both have similar characteristics in their respective. Gnu/linux is a secure and reliable operating system that runs Non-stop. SCSI is the obvious choice for reliable and high-performance storage. Both are also open source. Can download and read the various SCSI specifications from the T10 Technical Committee of the International On information Technology Standards (INCITS). Similarly, you can download the Gnu/linux source to understand their implementations. Each dominate in their respective industries, so it's not surprising this gnu/linux supports SCSI better than any other op Erating system out there. SCSI is a interesting interface to study because it is one of the oldest interfaces this is still today. The standard, called SCSI-1, is created by Shugart Associates 1979. SCSI-1 defined a 8-bit parallel interface with a 5MHz data clock, providing a maximum data transfer rate of 5 megabytes per second (MB/s).

The SCSI-2 standard began in 1985 and resulted in a faster data rate (10MHZ) and a wider bus (bits). Called Fast/wide, SCSI-2 allowed data transfer rates up to MB/s with backward compatibility and SCSI-1, albeit at the SCSI-1 data rate.

The development of SCSI-3 began in 1993 and is actually a collection of standards defining, protocols, command sets, and Si Gnaling methods. Under the moniker SCSI-3, you'll find a collection of parallel SCSI standards with the name Ultra and modern serial ased protocols such as the IEEE 1394 (FireWire), Fibre Channel, Internet SCSI (ISCSI), and the new kid on the block, SAS. These standards changed the storage landscape by introducing storage network technologies (such as Fc-al or ISCSI), extend Ed data rates above 1 gigabit per second (gbit/s), increased the maximum number of addressable devices (above), and Exte Nded the maximum cable lengths beyond. Figure 1 shows the data rate evolution of SCSI from 1986 through 2007.
Figure 1. The evolution of SCSI data rates

Back to Top

SCSI actors

SCSI implements a client/server style of communications architecture. A initiator sends a command request to a target device. The target processes the request and returns a response to the initiator. An initiator can represent a SCSI device in a host computer, and a SCSI target can is a disk drive, CD-ROM, tape drive, or Special device such as an enclosure service.

Back to Top

SCSI commands

While the protocols over which SCSI are transported have changed over the years, the SCSI command set retains many of its o Riginal elements. A SCSI command is defined within a command descriptor block (CDB). The CDB contains a operation code defining the particular operation to perform and a number of operation-specific Paramet ERs.

SCSI commands support reading and writing data (four variants each) and also a number of NON-DATA commands such as Test-un It-ready (is the device Ready), inquiry (retrieve basic information about the target device), read-capacity (Retrieve Stor Age capacity of the target device), and numerous others. The particular commands supported by a target device depend upon the type of device. An initiator identifies the device type through the inquiry command. Table 1 lists the Most-common SCSI commands you ' ll encounter.
Table 1. Common SCSI Commands

Command	Purpose
Test Unit Ready	Inquire whether the device is ready for transfers
Inquiry	Request basic information about the device
Request Sense	Request error information for a previous command
Read capacity	Request Storage Capacity Information
Read	Read data from the device
Write	Write data to the device
Mode Sense	Request mode pages (device parameters)
Mode Select	Configure device parameters in a mode page

With about sixty commands available, SCSI provides command capabilities for a wide range of devices (including random acce SS devices such as disks and sequential storage devices such as tape). SCSI also provides special commands to access enclosure services (such as current sensing and temperature within a storage enclosure). You'll have a information for more.

Back to Top

SCSI architecture in the Linux kernel

Figure 2 shows where the SCSI subsystem fits within the Linux kernel. At the top of the kernel are the system call interface, which handles the routing of User-space to calls their Destination in the kernel (such as a open, read, or write). The virtual file system (VFS) is the abstraction layer for the multitude of file systems which are supported in the kernel. This takes care of routing requests to the appropriate file system. Most of the file systems communicate through a buffer cache, which is a cache that optimizes access to the physical device s by caching recently touched data. The Next is the block device drivers layer, which contains the various blocks drivers for underlying. The SCSI subsystem is one of these blocks device drivers.
Figure 2. Where the SCSI subsystem fits in the Linux kernel

Not unlike-major subsystems in the Linux kernel, the SCSI subsystem exists as a layered architecture with three dist INCT layers. At the top is what's called the upper level, which represents the highest interface to the kernel for SCSI and drivers for The major device types. The Next is the mid level, also called the common or unifying layer. In this layer are common services for both the upper and lower of the SCSI stack. Finally, there ' s the lower level, which represents the actual drivers for the physical interfaces, are applicable to s CSI (Figure 3).
Figure 3. Layered architecture of the Linux SCSI subsystem

Can find the source for the SCSI subsystem (SCSI upper level, mid level, and a plethora of drivers) in./linux/drivers /scsi. SCSI data structures can is in the SCSI source directory and also in./linux/include/scsi.

Back to Top

SCSI Upper Level

The upper level of the SCSI subsystem represents the highest-level interface to the kernel level. It consists of a set of drivers such as the Block devices (SCSI disk and SCSI CD-ROM) and the character devices (SCSI tape and SCSI generic). The upper level accepts requests to above (such as the VFS) and converts into SCSI them. The upper layer also completes SCSI commands and notifies the layer of the status.

The SCSI disk driver is implemented in./linux/drivers/scsi/sd.c. The SCSI disk driver initializes itself with a call to Register_blkdev (as a block driver) and provides a common set of FU Nctions that represent all SCSI devices with Scsi_register_driver. Two of interest here are sd_probe and Sd_init_command. Whenever a new SCSI device is attached to a system, the Sd_probe function are called from the SCSI mid layer. The Sd_probe function determines whether the device would be managed by the SCSI disk driver and, if so, creates a new SCSI _disk structure to represent it. The Sd_init_command is the function this takes a request from the file system layer and turns the request into a SCSI read or write command (SD_RW_INTR is called to complete this I/O request).

The SCSI tape driver is implemented in./linux/drivers/scsi/st.c. The tape driver is a sequential access device and registers itself as a character device through. The SCSI tape driver also provides a probe function called St_probe. This is creates a new tape device and adds it into a vector called scsi_tapes. The SCSI tape driver is unique in that it performs I/O transfers directly from user spaces, if possible. Otherwise, data is staged through a driver buffer.

The SCSI CD-ROM driver is implemented in./linux/drivers/scsi/sr.c. The CD-ROM driver is another blocks device and provides a similar set of functions to the SCSI disk driver. The Sr_probe function is used to create a SCSI_SD structure to represent the CD-ROM device and also registers the CD-ROM W ITH Register_cdrom. The SCSI tape driver also exports a sr_init_command that turns a request into a SCSI CD-ROM read or write request.

Finally, the SCSI generic driver is implemented in./linux/drivers/scsi/sg.c. This is driver allows user applications to send SCSI commands to devices (such as format, mode sense, or diagnostic commands) . You can take advantage to the SCSI generic driver from user spaces with the Sg3utils package. This User-space package contains a variety of utilities for sending SCSI commands and parsing their.

Back to Top

SCSI Mid Level

The SCSI mid level are a common services layer for both the SCSI upper level and lower level (implemented partly in./linux /DRIVERS/SCSI/SCSI.C). It provides a number of functions that are used by Upper-and lower-level drivers and, therefore, serves as the glue En these two distinct layers. This layer is important because it abstracts the implementation of Lower-level drivers (LLD), partially implemented in. l INUX/DRIVERS/SCSI/HOSTS.C. This means is Fibre Channel host bus adapters (HBAs) with different interfaces The can is used in the same.

Low-level driver registration and error handling are provided by the SCSI mid level. The mid level also provides SCSI command queuing between the upper and lower. A key aspect of the SCSI mid level is conversion of command requests to the upper layer into SCSI requests. It also manages scsi-specific error recovery.

The mid layer fundamentally acts as a go-between for the upper and lower of the SCSI levels. It accepts requests for SCSI transactions and queues them for processing (as shown in./linux/drivers/scsi/scsi_lib.c). When this commands are completed, it receives the SCSI response from the LLD and performs for notification co Mpletion of the request.

One of the most important aspects of the mid layer is error and timeout handling. When a SCSI command does not complete within a reasonable amount to time or a error was returned for a SCSI request, the M ID level manages the error or retries the request. The mid level also manages higher-level recovery such as requesting an HBA (LLD) or SCSI device reset. The SCSI error and timeout handler is implemented in./linux/drivers/scsi/scsi_error.c.

Back to Top

SCSI Lower Level

At the lowest level is a collection of drivers called the SCSI low-level drivers. These are the "specific drivers" interface to the physical devices as such. The LLD provides an abstraction from the common mid layer to the Device-specific HBA. Each LLD provides "interface to" particular underlying hardware but uses the standard set of interfaces to the mid L Ayer.

The lower level contains the largest amount of the code because it accounts for the variations of SCSI adapter types. For example, the Fibre Channel protocol includes to LLD for adapters to Emulex and QLogic. LLDs for SAS adapters are included from Adaptec and LSI.

Back to Top

The future of Linux and SCSI

If there ' s one thing for sure, there's a future for SCSI, and it has a home in Linux. As SCSI evolves, Linux'll be there with support for the new cutting-edge advancements. Linux supports the new SAS protocol with drivers for a number of HBAs. As the protocols advance to greater speeds (such as 6 GB SAS or 8 GB FC), Linux would be on the forefront of development an D deployment.

You'll also find Linux at the cutting edge of new SCSI protocols. One that's important to mention are Fibre Channel over Ethernet (FCoE). FCoE is a mapping of Fibre Channel frames over full duplex Ethernet networks (typically 1Gb or 10Gb Ethernet). The FCoE is important because it joins the Most-dominant Enterprise storage protocol with the Most-dominant networking. This new technology would certainly be one to watch, and Linux would be there.

End-to-end data protection is also on the way for SCSI, coming out of the the T10 ' s new data integrity standard. This is standard adds a Data integrity field (DIF) to all sector to maintain data protection on the medium. The new 8-byte DIF field includes a cyclical redundancy code (CRC) to protect the data, a reference tag to protect against Misdirected writes, and an application tag. The application tag is specific to the application and can define the purpose behind the Data-part of PDF document Example. You'll have a information for more.

Back to Top

Summary

The Linux kernel is yet another model example of abstracted layered architecture. It joins disparate file systems of differing types to different physical storage. When those storage mediums are SCSI related, the SCSI subsystem translates the common Linux blocks requests into SCSI Reque STS for the particular underlying device. The SCSI subsystem itself has gone through many over the changes, and the years changes ' t was done aren. New technologies such as end-to-end data protection are finding their into Linux, as way new are protocols as such.

Resources

LearnCheck out the Technical committee T10 to learn more about the various SCSI specifications, from the fundamental commands O F SCSI to the newest SCSI protocols like SAS.

This is article from the ' Open Source Development Lab focuses on the 2.6 kernel and the SCSI disk driver to a detailed look a T the SCSI implementation in the Linux kernel.

This list is User-space tools to query, view, or manage SCSI devices makes with the "SCSI generic driver in" Linux ker Nel. (Linux supports a number of SCSI tools, including the sg3utils mentioned in this article.)

"Anatomy of the Linux kernel" (DeveloperWorks, June 2007) gives a general overview of the the Linux kernel and all of its Maj or subsystems.

"Kernel command using Linux system calls" (DeveloperWorks, March 2007) explores the system call interface within the Linux Kernel (from User-space to kernel completion).

"Anatomy of the Linux networking stack" (DeveloperWorks, June 2007) introduces the basic architecture of the networking St Ack in Linux, including the major components and structures that are involved.

"Anatomy of the Linux file system" (DeveloperWorks, October 2007) explores the virtual file system (VFS)-sometimes called The virtual filesystem switch-in the Linux kernel and then reviews some of the major structures that tie file systems Ther.

Fibre Channel over Ethernet (FCoE) are one of the interesting SCSI protocols coming in the future. It is not yet available but are actively under development by a number of vendors.

Learn the paper on the Data Integrity Field (DIF) technique for end-to-end protection. DIF provides protection on disk, detects misdirected writes, and allows application-specific tags to accompany the data fo R further protection. DIF is a multi-vendor technology, which means you'll find support to it in drives and HBAs to Variety.

In the DeveloperWorks Linux zone, find more resources for Linux developers, and scan our most popular, articles andtutorial S.

All Linux tips and Linux tutorials on DeveloperWorks.

Stay current with DeveloperWorks technical events and webcasts.

Get all products and Technologies With IBM trial software, available for download directly from DeveloperWorks, builds your next development project on Linux .

discuss Get involved in the DeveloperWorks community through blogs, forums, podcasts, and community at our new topics KS spaces.