FCL Error Recovery Policy Recommendations

Jim Mcgrath jmcgrath at QNTM.COM
Wed Sep 24 10:24:24 PDT 1997


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* jmcgrath at qntm.com (Jim Mcgrath)
*
     


     We had a good conference call Tuesday and I would like to relay to
     people three important items of substance before the T11 meeting in
     two weeks.
     
     First, John Scheible informed us that the working group believes that
     requiring the reporting of any new error conditions other than
     8b/10b and asperity error violations by intermediate nodes (a decision
     we made months ago) is not required.  So potential future topics
     like detecting and recovering lost credit, scrubber failures, etc...
     are not part of the long term SSWG agenda.  On the intermediate node
     error detection the topic of CRC was put to rest (no CRC detection)
     and John believes he has enough material to make the editorial changes
     required for the 8b/10b detection.
     
     On this first point the SSWG is declaring victory and closing the books.
     
     Second, we created a matrix for error recovery with two dimensions:
         the degree of threadedness between target and inititiator
             (no queueing, so only one command outstanding at a time,
             and queueing, so multiple commands (and thus errors) are
             outstanding at a time), and
         the level of error recovery
             (sequence, which could mean data retransmission without
             respect to data sequence boundaries, and exchange, or
             simply retrying the command):
     
     
     
     Are IO's queued?   Sequence or Exchange        Comment
                        Level Error recovery
     
     -----------------------------------------------------------------
     No                 Exchange              FC-AL today
     No                 Sequence              Tape today - Crossroads
                                                  class 3 proposal
     Yes                Exchange              Extend Crossroads and/or
                                                  Doug's class 2
     Yes                Sequence              NEVER DO
     
     
     The idea is that if a device like tape every wants to do queued IOs,
     then recovery will only be at the exchange level.  Note that early
     detection will still be provided with a class 3 and/or class 2
     mechanism, so the ULP timeout issue is still addressed.  This will
     require some reworking of commands and their usage on the part of
     the tape people, but a move of tape architecture to queueing
     sounds like a reasonable point to make that break.
     
     On this second point we would like to get feedback (reflector, 
     working group, T10 tape meeting).  I would suggest we consider
     a statement of future direction/policy for discussiona and
     possible approval by the working group.  I would suggest tenative
     approvel this month, with a rediscussion at the November T10 week
     meeting so as to get the T10 tape people involved.
     
     Third, it appears that the Crossroads proposal for solving the 
     immediate tape problem is ready from prime time.  Therefore 
     we will suggest working group discussion with the aim of
     forwarding on the proposal in its current form for approval
     at the December T11 plennary.  After that point the editors
     can carve it up into whatever suitable set of final reseting
     docuements the proposal wants to lie in.  The key is that
     developers can begin work with the confidence instilled
     by the plennary vote.
     
     Jim
     
     
     
*
* 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