Some comments on FC-TAPE v 1.06b

Talluto, Dennis dennis.talluto at
Fri Jul 10 14:10:18 PDT 1998

* From the T10 (formerly SCSI) Reflector (t10 at, posted by:
* "Talluto, Dennis" <dennis.talluto at>

Good points.

#6 - Granted that any discussion of IPI and other mass storage models would
be out of scope of this tape document edit, the only continuing point of
comment I would have is that the development of this standard not preclude
the development or use of peer-peer storage.  Likewise, I look forward to
dialogue in the industry that would lead to a consensed model and standard.

> # 37 & #48
>c)	This recommendation will flush out any real (as opposed to
>  	hypothetical) usage of it, allowing us to directly address
>   	the question in the profile.

Here is a real, non-hypothetical use for command linking/chaining - remote
electronic data vaulting.  We do it all the time.  Pick out some secure
facility, perhaps 100's or even 1000's of miles from the client's main site,
put in some large tape libraries with perhaps ten's of tape transports, and
connect the two sites with telecommunication links.  What happens in this
extended channel environment is that I/O channel propagation delay and
latency (when combined and measured) jumps from under 1 microsecond, to
perhaps 4 - 100 milliseconds (depending upon the circuit miles, transmission
facilities, and premise equipment).  Unless one is employing equipment
highly optimized to exploit this environment, the tape back-ups will grind
to a crawl.

It is our intent to deploy open systems tape subsystems in exactly this same
manner - perhaps by inserting some sort of neutral network transport to
carry the FC frames between geographically dispersed fabrics (national,
trans-national, transcontinental)(that is a whole other project... | ; - })
.  In this case, it would be highly advantageous to chain some
commands/operations to avoid the affect of latency.  Hence, you may wish to
chain multiple read operations, or write operations, or perhaps send the
sense or status command along with certain read/write op. This is feasible
if the nature of the I/O request and the results are clearly understood.
True, in a local configuration, unless one is performing massive amounts of
back-up operations, the effects of chaining are present but not that
obvious, and the business value may be difficult to measure.  However, the
larger the infrastructure, and the more geographically disperse it becomes,
the benefits become measurable and significant.

I urge careful consideration before elimination of command linking from this


From:  Bob Snively[SMTP:Bob.Snively at Ebay.Sun.COM]
Sent:  Friday, July 10, 1998 4:22 PM
To:  Bob.Snively at Ebay.Sun.COM; Talluto, Dennis
Cc:  fc at; t10 at Symbios.COM
Subject:  RE: Some comments on FC-TAPE v 1.06b


Thank you very much for your support on those issues that I consider
most important, those that support the creation of a truly interoperable
tape environment.

For some of the other questions you have, I would like to provide the
background I thought of while creating the comments.


> #6
> NameLastFirst: Snively, Robert
> Email: Bob.Snively at
> Phone: (510) 574-9051
> Fax: 
> CoOrg: Sun Microsystems
> Project: Project 1315DT, FC-TAPE, T11/98-124v7
> ClauseSubclause: 3.5
> PDFPage: 
> DocPage:  7
> Line: 
> CommentType: E
> Comment:
> Throughout this section, the words "FC-TAPE compliant 
> implementation" is used in a rather odd way.  The point is that
> "implementations" do not communicate with each other.  As an
> example, an FC-TAPE tape device cannot communicate with another
> FC-TAPE tape device.
> CommentEnd:
> SuggestedRemedy:
> I would propose that the many relevant places be modified to
> speak of "initiators" communicating with "targets", or alternatively,
> speak of "nodes" communicating with "complementary nodes".  As one
> in the second paragraph, the text "An implementation may use the 
> feature to communicate with non-compliant implementations." be 
> modified to read:  "An initiator may use the feature to communicate
> with non-compliant targets."  
> RemedyEnd:
> Talluto comment: I do not have the specific detailed knowledge on this,
> I would not want to see the possibility of peer-peer storage elements
> prohibited in anyway.  True, in today's environment, with SCSI protocols
> initiator/target relationships, direct disk-disk, disk-tape, and tape-tape
> are not implemented (I know that there are some proprietary deliverables
> using microprocs/microkernels, but that is a whole other breed).  What we
> are interested in pursuing with some of our suppliers is IPI-3
> and functions, that will allow brokered or third party I/O under the
> management of an appropriate integrity manager.  I would just hate to see
> peer-peer devices precluded.  Please correct me if I am wrong and this
> not pertain.

This is really a two-part discussion.  First,  SCSI is really designed
as a peer-to-peer structure.  One node requests that a service be performed,
while another node accepts that request and performs the service.  The
node requesting the service for a particular command is the "initiator",
while the node performing the service for that command is the "target".
Any node can take on any combination of initiator and target roles,
on what functions it chooses to provide.  For this particular profile,
we are identifying the actions of two complementary nodes, an initiator
driven by a tape driver to request certain functions of a target, which
to be able to perform tape services.  For one example, a tape device that
chooses to support the disk copy function (not required by this
profile) may accept a copy command as a tape device, then initiate a
disk operation as a disk initiator.  A profile only provides the limits
of interoperability and guaranteed function for the subset of behaviors it

A second part is how direct data transfers may take place in a system
that has a separate integrity manager.  I believe that the IPI-3
third party capability is a less than ideal way to achieve this.  Error
recovery can become at best most interesting, and at worst a nightmare.
It turns out that the data mover functions proposed by the IEEE Mass Storage
Model are very nicely performed by SCSI.  The only question is what
kicks off the data mover function.  At present, there are several ways
already proposed or used, including low-level messaging, TCP-IP out-of-band
communication and TCP-IP communication through the FC-IP path (which can
co-exist with SCSI-FCP on a particular FC link).  Once the SCSI command
is kicked off, it gets the full benefit of the highly performance-tuned
and very robust and well-protected SCSI data transfer process.  This
makes more sense to me than any of the third-part mechanisms, since there
is always guaranteed to be a direct error-feedback and management path
for each portion of the operation.

I look forward to future efforts to standardize this.

> #13
> NameLastFirst: Snively, Robert
> Email: Bob.Snively at
> Phone: (510) 574-9051
> Fax: 
> CoOrg: Sun Microsystems
> Project: Project 1315DT, FC-TAPE, T11/98-124v7
> ClauseSubclause: 5.2
> PDFPage: 
> DocPage:  13
> Line: 
> CommentType: T
> Comment:
> In Table 4, features on line 2, 4, and 7 indicate that Class 3
> behavior is optional.  Class 3 behavior should be mandatory.  If
> all initiators and the target support Class 2, Class 2 behavior 
> should be used.  
> CommentEnd:
> SuggestedRemedy:
> In Table 4, change the features "Class 2" on lines 2, 4, and 7 to be
> invokable by the NL_Port originator and required by the
> NL_Port responder.  
> Change Note 1 of Table 4 to read:
> 	Implementations conforming to this profile shall support
> 	Class 3.  If all initiators attached to a target support
> 	Class 2, the target may choose to operate with Class 2.
> RemedyEnd:
> Talluto comment: I fail to see the difference between the results of the
> comment and the results of the suggested remedy.  It seems that both
> statements allow for the support of either class2 or class3.  The only
> impact that I could see is if someone would choose to implement class2
> drivers only - that would be prohibited. 

That is precisely the point.  I would like any compliant tape device to
be able to operate properly whether it is attached to an initiator
that supports class 3 only or both class 2 and class 3.  

> # 37 & #48
> NameLastFirst: Snively, Robert
> Email: Bob.Snively at
> Phone: (510) 574-9051
> Fax: 
> CoOrg: Sun Microsystems
> Project: Project 1315DT, FC-TAPE, T11/98-124v7
> ClauseSubclause: 11.3
> PDFPage: 
> DocPage:  58
> Line: 
> CommentType: T
> Comment:
> Command linking should be prohibited.
> CommentEnd:
> SuggestedRemedy:
> Rewrite 12.3 to read:
> "The use of command linking is prohibited by devices conforming to this
> profile."
> RemedyEnd:
> Talluto Comment: If this is the same as 'command chaining', why should
> be prohibited in an intelligent storage controller?

Command linking was originally intended to provide something like the 
FIPS-60 command chaining.  Fortunately, the new capabilities provided by
the SCSI interface, including command queueing, data buffering, automatic
seek and seek recovery, and abstract addressing have made the command
chaining required by the old Count/Key/Data type devices obsolete.

Command linking has not been implemented by any disk drive.  It has not
been implemented or used by any open tape drive.  The rumor mill
persists that there may be some proprietary host adapter and tape
implementations that use it, but such devices would either deal with
the lack of command chaining or fail in an open system environment.

Command linking was at one time used as a performance enhancement, but
now that SCSI operations are all performed by scripted co-processors
and hardware, that function has also vanished.

The only remaining possible use that I can imagine is some sense that
commands within a chain will be executed in a known order.  Of course
commands outside the chain will not be ordered with respect to those
within the a chain.  However, there are two ways to do this already,
using either the queueing attributes or by ordering execution from
the initiator.  

Since command linking has not been implemented, it is difficult to
verify that there are not holes in the architecture, especially with
respect to ordering and error reporting.

Therefore, I have recommended prohibiting the use of command linking 
and any requirement to make command linking available in profile 
compliant environments.  There are three major reasons for this.

   a)	It contributes significantly to complexity with no known
   b)	It is not exercised well enough to guarantee that there are no
   	major architectural holes in the definition.

   c)	This recommendation will flush out any real (as opposed to
   	hypothetical) usage of it, allowing us to directly address
   	the question in the profile.

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list