Concerns with SCSI-3 serial channel mappings.
dallas at zk3.dec.com
dallas at zk3.dec.com
Tue Apr 30 11:51:05 PDT 1996
* From the SCSI Reflector, posted by:
* dallas at zk3.dec.com
This is the first in a series of postings to the SCSI Reflector. The
purpose of these postings is to raise a number of concerns/issues and
to start discussions on the limitations of some of the serial channel
protocol mappings for SCSI-3. My concerns are from the host operating
system point of view and should be taken in that light. If other
software implementors have the same or other concerns with the serial
channel mappings, please let them be known.
If there is enough concern from software implementors on the serial
channel mappings for SCSI-3, a separate reflector can be established
for email discussions. If needed, a series of meetings or conference
calls could also be arranged for discussion of the issues.
With the risk of taking some serious flames I will make the following
observations. From the O.S. perspective the SCSI-3 serial channel
mappings are a mess and require major modifications. This posting will
be focusing on error case behavior and the delivery order of tasks.
Each SCSI-3 serial channel presents its own behavioral characteristics
for channel errors. These affect all layers of the host I/O subsystem,
including the peripheral driver. If my memory serves me right, one of
the original objectives of SCSI-3 was the transparency of the physical
interconnect to the peripheral drivers. In my opinion this objective
has not be met.
To better explain my concern, I would like to explain some implicit
behavior that is present in the SCSI-2 parallel bus. The parallel bus
behavior may be characterized as deterministic (e.g., that for a
command its ordering and behavior can be described as it relates to
other commands within a command stream). Without this behavior,
ordered tagged commands as defined by SCSI-2 don't work.
Task management functions by their nature must be ordered in relation
to I/O tasks. For example, if an abort tag task is sent, receipt of
the abort tag task must be AFTER the receipt of the I/O task by the
Logical Unit. Otherwise, the command will be executed.
For the sake of this discussion (if you have not guessed) my view point
is that command and task management delivery order and receipt by a
Logical Unit, whether tagged or non tagged, must be deterministic.
This means that the Logical Unit must receive commands and task
management functions in the order specified by the peripheral driver.
This also means the peripheral driver shall receive an indication when
a command or task management function has not been received by the
Logical Unit or entered into the task set. In SIP, we require a
selection timeout or the return of QUEUE FULL or BUSY status without an
intervening bus free.
For the SCSI-2 parallel bus, the arrival order of tagged commands at a
Logical Unit is deterministic and can also be characterized as having
other deterministic properties. These properties are how the host
software wishes a particular command to be operated on relative to
other commands within the Logical Unit and commands yet to be received
by the Logical Unit (simple, ordered and head of queue attributes).
Command sending to a Logical Unit can also be controlled based on the
needs of the host software. If the host determines that a particular
Logical Unit's command delivery must be deterministic, then software
mechanisms can be employed to prevent an initiator from sending any
pending commands (e.g., waiting to be sent) to a Logical Unit, if the
current command has not been entered in the Logical Unit's command
queue (e.g., Queue Full). The mechanisms employed allow host software
intervention to determine what corrective actions are needed for this
command. For example, do other commands rely on the ordering of this
command, is this a timed I/O command and have we missed our marker
(video), or real-time I/O and this command must be upgraded in priority.
An example of a deterministic command ordering tag model is that an
application has certain dependencies on I/O ordering for a limited set
of operations but most I/O operations may be reordered within a certain
set of I/O operations. In this case an application may send simple
tagged I/O requests as part of a bounded set of operations but requires
the set to be completed before acting on another set. This can be
accomplished by sending an ordered tag I/O operation to mark each of
the set boundaries. If an boundary marker (Ordered tag) is rejected by
the Logical Unit (not entered into the command queue, QUEUE FULL
status), the host software can reissue the boundary SCSI command to
the Logical Unit, preserving the bounded set of operations.
In some of the SCSI serial channel protocols the above example is not
possible; command order delivery is adhoc for tagged commands. If this
type of functionality is needed by your applications/drivers, you must
first determine the devices physical interconnect. If it is one of the
interconnects that does not support ordered delivery for tagged
commands, then either you never issue tagged tasks to the Logical Unit
or you issue simple tagged tasks in the bounded set and issue a
non-tagged task as your boundary marker. In either case performance
suffers resulting in a giant step backward compared to SCSI-2.
The above dealt with disks. Now we will examine tapes. Systems today
deal with huge amounts of disk data storage which still needs to be
backed up to a secondary storage medium (tapes). Our customers are
demanding increased performance from tapes given the amount of data
that needs to be backed up. Over the years SCSI tape drive transfer to
medium speeds have improved and will only get better to handle the
demands placed upon them. One of the biggest impacts to tape drive
performance is keeping the drives streaming. The write buffer
functionality within the drives helps keep performance up but at the
cost of complicated software error recovery.
The problem with the use of a tape drives write buffer is that good
completion status is returned when all the write data is entered into
the buffer not when the data is successfully placed on the media. The
result of this behavior is that the application is not notified of an
error with a particular record (write command) but at some future point
in time on the response from another command. The reporting of a write
failure may not even be on a future media modification command (e.g.,
rewind). This type of behavior makes the error recover process
complicated for applications and peripheral drivers.
ACA and tagged commands in SCSI-3 allows the host and applications
software the mechanisms for a deterministic error recovery policy in
the context of the command that failed and not in the context of an
unrelated command. Tagged commands with ACA for tape drives is a good
thing, the combined functionality of error reporting in the context of
the command and tagged commands only enhances tape operations and
The issuing of ordered tagged tasks to tape devices on some of the SCSI
interconnects is precluded due to no guarantee of command ordering.
Stream devices require guaranteed command ordering to due their
inherent nature. It has been argued that this functionality is not
needed in tapes, but I argue that it has been needed for a number of
years and is definitely needed now.
In summary, it is my opinion that most host software requires the
1. The SCSI interconnects shall not present behavioral differences to
2. The SCSI interconnects shall guarantee command and task management
function sequence ordering in all classes of operation.
My organization within DIGITAL expects any vendor's components we are
or will be evaluating to have resolved the concerns listed in this
posting. The consistent set characteristics needed for our software
are probably the same (with variations) as other software vendors. One
of the goals of any meetings or conference calls can be a common base
set of attributes for SCSI-3 adaptors (SPI,FCP,SSA, and SBP) and
devices in our purchase specs. The base set of attributes does not
preclude any vendor adding other value added attributes/features to
their purchase specs.
My next posting topic will be SCSI device addressing and uniquely
identifying a device.
More information about the T10