Some comments on FC-TAPE v 1.06b

Bob Snively Bob.Snively at Ebay.Sun.COM
Fri Jul 10 13:22:04 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Bob Snively <Bob.Snively at Ebay.Sun.COM>
*

Dennis,

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.

Bob

> #6
> 
> NameLastFirst: Snively, Robert
> Email: Bob.Snively at sun.com
> 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 example,
> 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, but
> I would not want to see the possibility of peer-peer storage elements
> prohibited in anyway.  True, in today's environment, with SCSI protocols and
> 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 capabilities
> 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 does
> 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, depending
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 happens
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
considers.

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 sun.com
> 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 sun.com
> 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 that
> 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
   	benefit.
   	
   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 symbios.com





More information about the T10 mailing list