use of class 2 for tapes on FC-AL loops

Doug Hagerman, Digital Equipment, 508-841-2145, Flames to /dev/null 17-Apr-1997 1728 hagerman at miss.ENET.dec.com
Thu Apr 17 14:31:55 PDT 1997


* From the SCSI Reflector (scsi at symbios.com), posted by:
* "Doug Hagerman, Digital Equipment, 508-841-2145, Flames to /dev/null  17-Apr-1997 1728" <hagerman at miss.ENET.dec.com>
*
In reference to his proposal for using Class 2 to solve the tape problem,
presumably what Jim is referring to is the use of Class 2 as described in
the FCSI profiles plus FCP plus the SSC device model. (I don't know of
any other proposals.) This is fine with me, but I would like to hear
about the following questions:

1. Would this work with current Class 3 hardware?

2. Where in FCSI or FCP is the recovery process documented? As far as I
can find there are a number of error conditions, and in every case the
response to the error is to terminate both the sequence and the exchange.
This is exactly the problem in the case of tapes. Class 2 helps detect
some of the errors, but doesn't have anything to do with the recovery.

Perhaps I just can't read; could someone help me find the appropriate
paragraphs in FCSI or FCP?

3. Using what class does one send the INQUIRY command to a LUN in and
SCC device, not knowing in advance whether it is a tape or a disk?

I think what is needed at this point is a pair of proposals, one for
Class 2 and one for Class 3, each of which purports to solve the various
difficulties. Given that we could select the less objectionable...

Doug.

----------
From:	"jmcgrath at QNTM.COM\"
Sent:	Tuesday, 15 April, 1997 2:57 PM
To:	Douglas Hagerman
Subject:	FCL Error SSWG Conference Call for Today

<<File: 4-1-97.doc>><<File: 3-18-9~1.doc>>
* From the SCSI Reflector (scsi at symbios.com), posted by:
* jmcgrath at qntm.com (Jim Mcgrath)
*
--IMA.Boundary.701721168
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

     
     
     I sent out an announcement as normal last week, but I did not check
     to see if it was reflected by FC at Network.Com.  Indeed, it had not been
     (is that reflector ever going to get back up?), so the conference call
     for today has been cancelled.
     
     The next conference call is scheduled for 
                     Tuesday, April 29, 9am to 11 am PST.
     
     I will send out the phone numbers in a later message.  
     Enclosed with this message are the minutes for the last two meetings.
     
     The FC working group feedback last week was that some reasonably
     low timeout based on a low E_D_TOV value was OK for us to work 
     with for sequence level error recovery.  The fabric people said that
     the existing value was chosen so that it was easy to hit.  They
     cautioned that values lower than hundreds of ms might be a problem,
     especially if the delay is caused by congestion (which is time
     variable), not topology.
     
     I would like to suggest that we consider using this order of
     timeout for a sequence level error detection and recovery technique.
     While this restricts the time spent in the interconnect, we have
     to decide on other assumptions the sender and receiver of frames for
     the sequence can have on the receiver and sender respectively.  That
     is, the interconnect time delay is only one element that should be
     used to trigger a timeout below the ULP mechanism.  What assumptions
     should we make about a receiver's ability to issue new buffer
     credits in a timely manner?  What assumptions should the receiver
     make, after granting credits, about the ability of the sender to
     respond in a timely manner?  Are we always assuming that the non
     interconnect delays are essentially 0?
     
     The tape people gave some more presentations on problems with
     tape and FC.  I would like to propose (and get response from
     people) the following on this issue: given our October deadline,
     and the fact that none of the alternatives that address this 
     problem (tape operations in a non queued or queued but only 1
     command deep environment, so we do not have the out of order
     command problem) cleanly, why not require class 2 behavior when
     talking to a tape drive?
     
     I would like to propose the the Error SSWG adopt this solution
     as the incumbant solution and make sure it addresses tha logical
     problems raised by tape people.  Its overwhelming advantage over
     any other approach is that it is an already dfined solution.  If
     we can find specific faults with this approach, then we can invite
     alternative proposals that address those points or are simplier
     (in some sense) than class 2.  My goal here is to provide closure
     on this issue - we have been discussing it for far too long without
     concrete proposals on the table that can lead to closure.
     
     On link level error recovery, we still need to define the criteria
     for making a decision on whether we need it (given higher level of
     error recovery).  For instance, is it performance?  If so, under
     what circumstances and what is the expected performance gain?  My
     philosophy is that we should entertain error recovery additions
     only for a reason.  We seem to have a desire to avoid ULP timeouts,
     but at the end of the day it does not seem likely we need a 
     sequence level error recovery and a link level error recovery -
     unless we find their benefits are additive, we should be trying to
     simplify our life and focus on one of them.
     
     
     Jim
     
     

*
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com




More information about the T10 mailing list