SCSI协议-SAM4/SPC4/SBC3

1. SCSI client-sever model

SCSI client-server传输模型有以下特征：

(1) A client-server transaction isrepresented as a procedure call with inputs supplied by the caller (i.e., theclient). The procedurecall is processed by the server and returns outputs and a procedure call status.A client directs requests to a remote server via the SCSI initiator port andservice delivery subsystem and receivesa completion response or a failure notification.The request identifies the server andthe service to be performed and includes the input data.The response conveys the output data and request status. A failure notificationindicates that a condition has been detected (e.g., a reset or service deliveryfailure) that precludes request completion.

(2) Each SCSItarget device provides servicesperformed by device servers and task management functionsperformed by task managers. Alogical unit is a class that implements one of the device functional models described in the SCSI commandstandards and processes commands (e.g.,reading from or writing tothe media). Each command defines a unit of work to be performed by the logicalunit that may be externally referencedand controlled through requests issued to the task manager.

(3) All requests originate fromapplication clients residing within a SCSI initiator device. An application client is independent of the interconnect and SCSItransport protocol(e.g., an application client may correspond to thedevice driver andany other code within the operatingsystem that is capable of managing I/O requestswithout requiring knowledgeof the interconnect or SCSI transport protocol).

2. SCSI I/O system

The SCSI structural modelrepresents a view of the classes in a SCSI I/O system as seen by theapplication clients interacting with thesystem. As shown in figure 11, the fundamental class is the SCSI Domain class that represents an I/O system. A SCSIdomain is made up of SCSIdevices and a service delivery subsystem that transports commands, data, task management functions, and related information. A SCSI device contains clientsor servers or both and theinfrastructure to support them.

3. SCSI command model

The SCSI command set assumes an underlying request-response protocol. The fundamental properties of the request-response protocol are defined in SAM-4. Action on SCSI commands shall not be deemed completed until a response is received. The response shall include a status that indicates the final disposition of the command. As per SAM-4, the request-response protocol may be modeled as a procedure call, specifically:

Service response = Execute Command (IN (I_T_L_Q Nexus, CDB, Task Attribute, [Data-In Buffer Size], [Data-Out Buffer], [Data-Out Buffer Size], [Command Reference Number], [Command Priority]), OUT ([Data-In Buffer], [Sense Data], [Sense Data Length], Status))

3.1 SCSI command model中client的输入参数

SCSI command model中需要application client填充的参数有I_T_L_Qnexus，CDB，Task Attribute，Data-in Buffer Size（带内数据由deviceserver转递给applicationclient），Data-Out Buffer（带外数据由applicationclient转递给devicesever），Data-OutBuffer size，CRN，Commandpriority 8个参数.

3.2 SCSI command model中server的输出参数

SCSI command model中deviceserver响应的有5类参数（某种条件下这些参数并不会完全呈现），有：Data-InBuffer，SenseData(位于带内数据中)，SenseData Length，Status，StatusQualifier。其中SenseData可以作为当Status值为CHECKCONDITION时的“感应数据”（其他状态值Sense Data为空），也可以作为REQUESTSENSE命令的response。

4. SCSI command set: CDB introduction

CDB作为SCSI协议传输的基本单位有以下几种类型：定长CDB（fixedCDB），变长CDB（variableCDB），拓展CDB（XCDB），本文只介绍定长CDB：

(1) 6-byte commands CDB

(2) 10-byte commands CDB

(3) 12-byte commands CDB

(4) 16-byte commands CDB

5. Block device type feature

Block device overview:

Direct-access block devices store data for later retrieval in logical blocks. Logical blocks contain user data, may contain protection information accessible to the application client, and may contain additional information not normally accessible to the application client (e.g., an ECC). The number of bytes of user data contained in each logical block is the logical block length. The logical block length is greater than or equal to one byte and should be even. Most direct-access block devices support a logical block length of 512 bytes and some support additional logical block lengths (e.g., 520 or 4096 bytes). The logical block length does not include the length of protection information and additional information, if any, that are associated with the logical block. The logical block length is the same for all logical blocks on the medium.

Each logical block is stored at a unique LBA, which is either four bytes (i.e., a short LBA) or eight bytes (i.e., a long LBA) in length. The LBAs on a logical unit shall begin with zero and shall be contiguous up to the last logical block on the logical unit. An application client uses commands performing write operations to store logical blocks and commands performing read operations to retrieve logical blocks. A write operation causes one or more logical blocks to be written to the medium. A read operation causes one or more logical blocks to be read from the medium. A verify operation confirms that one or more logical blocks were correctly written and are able to be read without error from the medium.

5.1 Media

(1) Rotating media:

The typical application of adirect-access block device is a magnetic disk device. The medium is a spinningdisk with a magnetic material thatallows flux changes to be induced and recorded. An actuator positions aread-write head radially across the spinningdisk, allowing the device to randomly read or write the informationat any radial position. Data is storedby using the write portion of the head to record flux changes and is readby using the read portion of the headto read the recorded data.

(2) Memory media:

Memory media is based on solidstate random access memories (RAMs) (e.g., static RAM (SRAM), dynamicRAM (DRAM), magnetoresistive RAM(MRAM), ferroelectric RAM (FeRAM), or flash memory). Memorymedia-based direct-access block devices may beused for fast-access storage. Memory media may be volatile (e.g., SRAM or DRAM)or non-volatile (e.g., SRAM or DRAM with battery backup, MRAM, FeRAM, or flashmemory).

5.2 Logical and Physical blocks

(1) Logical blocks:

Logical blocks are stored on themedium along with additional information that the device server uses tomanage storage and retrieval. The formatof the additional information is defined by other standards or isvendor-specific and is hidden from the applicationclient during normal read, write, and verify operations. Thisadditional information may be used to identify the physical location of the blocks of data, the address of thelogical block, and to provide protectionagainst the loss of user data and protection information, if any (e.g., bycontainingECC bytes)

(2) Physical blocks :

A physical block is a set of databytes on the medium accessed by the device server as a unit. A physicalblock may contain (a) a portion of alogical block (i.e., there are multiple physical blocks in the logicalblock)(e.g., a physical block lengthof 512 bytes with a logical block length of 2 048 bytes); (b) a single completelogical block; (c) more than one logical block (i.e., there are multiplelogical blocks in the physical block)(e.g., aphysical block length of 4 096 bytes with alogical block length of 512 bytes).

(3) Logical blocks与Physical blocks之间的关系：

5.3 Initialization process

Direct-access block devices may require initialization prior to write, read, and verify operations. This initialization is performed by a FORMAT UNIT command. Parameters related to the format (e.g.,logical block length) may be set with the MODE SELECT command prior to the format operation. Some direct-access block devices are initialized by means not specified in this standard. The time when the initialization occurs is vendor-specific.

Direct-access block devices using a non-volatile medium may save the parameters and only need to beinitialized once. However, some mode parameters may need to be initialized after each logical unit reset. Acatastrophic failure of the direct-access block device may require the FORMAT UNIT command to be issued.Direct-access block devices that use a volatile medium may need to be initialized after each logical unit reset prior to the processing of write, read,or verify operations. Mode parameters may also need initialization afterlogical unit resets.

5.4 Write protection

Write protection prevents thealteration of the medium by commands issued to the device server. Writeprotection is usually controlled by the user of the medium through manual intervention (e.g., mechanical lock) or may result from hardware controls(e.g., tabs on the media housing) or software write protection. All sources of write protection are independent. When present, any write protection shall cause otherwise valid commands that request alteration of themedium to be rejected with CHECK CONDITION status with thesense key set to DATA PROTECT. Only when all write protections are disabled shall the device server process commands that request alteration of the medium.

Software write protection results when the device server is marked as write protected by the application clientusing the SWP bit in the Control mode page (see SPC-4). Software write protectionis optional. Changing the state of software write protection shall not preventpreviously accepted data (e.g., data in cache) from beingwritten to the media.

5.5 Write failures

If one or more commands performingwrite operations are in the task set and are being processed whenpower is lost (e.g., resulting in avendor-specific command timeout by the application client) or a medium erroror hardware error occurs (e.g.,because a removable medium was incorrectly unmounted), then the data inthe logical blocks being written bythose commands is indeterminate. When accessed by a commandperforming a read or verify operation (e.g.,after power on or after the removable medium is mounted), thedevice server may return old data, newdata, or vendor-specific data in those logical blocks.Before reading logical blocks whichencountered such a failure, an application client should reissue anycommands performing write operations thatwere outstanding.

5.6 Medium defects

Any medium has the potential fordefects that cause data to be lost. Therefore, each logical block may containadditional information that allows thedetection of changes to the user data and protection information, if any,caused by defects in the medium or otherphenomena, and may also allow the data to be reconstructedfollowing the detection of such a change(e.g., ECC bytes).

A defect causes a recovered error if the device server is able to retrieve the data by retrying orusing the additional information toreconstruct the data. A defect causes an unrecovered error if the deviceserver is unable to retrieve the data.Direct-access block devices may allow theapplication client to examine and modify the additional informationby using the READ LONG commands andthe WRITE LONG commands. Theapplication client may use the WRITE LONGcommands to alter the additional information to test the defectdetection logic of the direct-access blockdevice or to emulate a logical block with an unrecovered read errorwhen generating a mirror copy. This mayinduce a recovered error or an unrecovered error.

5.7 Caches

Cache existsseparately from the medium and is not directlyaccessible by the application client. Use of cache for write orread operations may reduce the accesstime to a logical block and increase the overall data throughput.

(1) During read operations, the device server uses the cacheto store logical blocks that the application client may request at some future time.The algorithm used to manage the cache is not part of this standard. However,parameters are provided to advise the deviceserver about future requests, or to restrict the use of cache for aparticular request.

(2) During write operations, the device server uses the cacheto store data that is to be written to the medium at a later time.This is called write-back caching. The command may complete prior to logicalblocks being written to themedium.

Application clients may use theforce unit access ( FUA ) bit in the CDB of commands performing write or readoperations to specify that the device servershall access the medium. For a writeoperation, setting the FUA bit to one causes the device server tocomplete the data write to the medium before completing the command.For a read operation,setting the FUA bit to one causes the device server toretrieve the logical blocks from themedium rather than from the cache.

When the cache becomes full oflogical blocks, new logical blocks may replace those currently in the cache.The disable page out ( DPO ) bit in the CDB of commands performing write, read, or verify operations allows the application client to influence the replacementof logical blocks in the cache. For writeoperations, setting theDPO bit to one specifies that the device server should not replaceexisting logical blocks in the cache with thenew logical blocks being written.For readand verify operations,setting the DPO bit to one specifiesthat the device server should not replace logicalblocks in the cache with the logical blocks that are being read. When the DPO and FUA bits areboth set to one, write and read operations effectively bypass the cache.