Addressing serial concerns about serial stream devices

Bob Snively Bob.Snively at Eng.Sun.COM
Fri Jul 19 13:08:56 PDT 1996


* From the SCSI Reflector, posted by:
* Bob.Snively at Eng.Sun.COM (Bob Snively)
*

To:	  Distribution

From:	  Bob Snively

Date:	  7/18/96

Subject:  Analysis of tape operation in SCSI-3 applications

1)  EXECUTIVE SUMMARY:

The work of the SSC working group considered a number
of tape issues, focusing on the characteristics of tape
devices operating on a Fibre Channel connection.

The discussion analyzed the attachment of tape drives
using the Class-3 Public Loop Disk Attachment profile.
In addition, it considered some possible improvements
to tape drive behavior as well as some significant
modifications to the tape drive model.  I was asked by
the SSC working group to explain the tentative conclusions
of the group about how this can be done in a simple manner.

The committee recognized two general classes of tape
behavior.  One class supports present SCSI-2 tape functionality
on Class-3 Public Loops.  No major changes are required to the
Public Loop Disk Attach profile to allow this.

The second class supports improved tape performance and recovery.
These improvements require the use of some protocol conventions
and the use of Class-2 links or loops.  A likely profile to include
this is either an extension of the the Public Loop Disk Attach profile
or inclusion in the Fabric Loop Attachment profile.

I expect that other serial links have similar properties, but 
am not familiar with all the nuances of those protocols.

2)  CLASS-3 PUBLIC LOOP SUPPORT OF SCSI-2 TAPE FUNCTIONALITY

The present tape functionality defined for parallel SCSI
can be implemented on the Class-3 Public Loop.  Typical
tape functionality uses command and data buffering to
allow normal data streaming behavior of the tape device.  In
the presence of a medium error during writes, a deferred error 
is generated, which normally involves a recovery procedure 
that obtains the buffered but unwritten data from the tape 
drive and the execution of a new series of write commands to 
transfer the unwritten data.  The writing of file marks can
also be buffered, but may involve more sophisticated recovery
procedures, perhaps requiring rewriting the full file from
the last file mark.

This functionality requires that the Class-3 Public Loop be
used in the following manner:

  a)	Commands are executed one command at a time.

	This requires that the commands either be untagged
	or that each tagged command not be originated by
	the application until the previous command's completion
	status has been received.

	To maintain streaming, command and data buffering may
	be required.  This function (commonly called lieing writes)
	may generate deferred error conditions.

   b)	Initiators allow the retransmission of data.

	If a link transfer error is detected, the target may
	optionally request the retransmission of the damaged
	sequence by completing the transfer of the damaged
	sequence and requesting it again using the XFER_RDY IU.
	This is a normal FCP behavior.

Using these two conventions, proper SCSI-2 behavior of the 
tape device will occur.  The recovery protocols will be fully
compatible with most present-day tape drives.  

Tape drive performance is maintained at or above today's norms by the
buffering of commands.  The theoretical limits are associated
with the link data rate, link utiliation, buffer size, buffer 
management, and data rate to the tape medium.

Command or status transfer failures are detected by host 
ULP timeouts.

3)  SIMPLIFIED RECOVERY USING CLASS-2 LOOPS

The tape drive recovery algorithm can be simplified if no
deferred status is required to present buffered error
conditions.  This can be done by queueing a number of tape
drive commands.  Ordering of the commands can be 
explicit using the ordered attribute or may be implicit if
the particular host adapter implementation services command
blocks in the order received (not a SCSI requirement).

The data for the queued commands is pre-fetched as required by
the tape drive.  As each command is executed and the transfer of
data to the tape medium is successfully completed, the status for
the corresponding command is transmitted back to the application
client.  If an error occurs during the transfer to the medium,
the status for the failing command can be transmitted correctly.
The remaining commands can be aborted and the recovery command 
can be generated to continue writing where the failing command
left off.  The aborted commands can then be re-emitted by the
application.  This ties the command execution tightly to the
status such that deferred error recovery is never required.  

NOTE:  THIS IS NOT PRESENT SCSI BEHAVIOR UNLESS THE SCSI COMMANDS
	ARE EXECUTED ONE AT A TIME.

The functionality required to allow this capability is not defined
by any profile but would include the following:

   a)	Class 2

	Class-2 behavior on FC or FC-AL is required to provide
	explicit acknowledgement of the successful delivery of one command
	so that the next command can be correctly ordered.  Note
	that this still does not guarantee ordering completely
	unless the device server is guaranteed to recognize the
	commands in the same order that they are received and acknowledged.

	Class-2 behavior is also required to provide explicit
	acknowledgement of the successful delivery of status.  

   b)	Synchronous command block transfer

	Each command block must be transmitted and acknowledged before
	the next command block is transmitted to guarantee that the
	commands are ordered correctly. 

	Note that acknowledgments actually do not guarantee delivery,
	but only provide a much shorter bounded timeout in the case
	of non-delivery.  Fibre Channel recovery procedures exist for
	the case of such timeouts.

   c)	Initiators allow the retransmission of data.

	If a link transfer error is detected, the target may
	optionally request the retransmission of the damaged
	sequence by completing the transfer of the damaged
	sequence and requesting it again using the XFER_RDY IU.
	This is a normal FCP behavior.

Using these three conventions, proper operation of a queued 
tape device will occur.  The recovery protocols will be incompatible
with all present tape drive recovery procedures.  

Tape drive performance is maintained at or above today's norms by the
queueing of commands and the buffering of data.  The theoretical limits 
are associated with the link data rate, link utiliation, buffer size, buffer 
management, and data rate to the tape medium.  I do not expect that
significant performance differences for a similarly architected tape
drive will be noticeable with respect to the Class-3 PLDA behavior.

Command or status transfer failures are detected by acknowledgment timeouts.  
More complex failures still require ULP timeouts for recovery. 

If the device server has any mechanisms that generate deferred errors,
the old style error recovery is required in addition to the simplified
error recovery (resulting in a net increase in recovery  complexity). 


PRINTERS:

Printer behavior was also discussed because of its similarity with
tape drive writes.  If buffered printer operation is acceptable, 
either of these mechanisms could be used for printer streams.
Note that printers doing things like check printing may still 
want to provide separate synchronized operations for each check
to be written, avoiding any possibility of reprinting an already-printed
check.



-------------------------------------------------------------------------------

Bob Snively				         Phone:	   (415) 786-6694
Sun Microsystems Computer Company	         FAX:	   (415) 568-9603
Mail Stop UMPK 12-204
2550 Garcia Avenue			   	 E-mail:   bob.snively at sun.com
Mountain View, CA 94043-1100
-------------------------------------------------------------------------------




More information about the T10 mailing list