FC-TAPE: Lost Read Data Sequence detection

Binford, Charles charles.binford at symbios.com
Fri Oct 23 10:12:49 PDT 1998

* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* "Binford, Charles" <charles.binford at symbios.com>
At the last FC-Tape meeting in Florida I brought up an issue which we
did not have time to fully discuss.  I was given an action item to
explain it on the reflector.  Well, here it is......

My concern is detecting lost Read Data sequences under class 3.  If a
target breaks the read data IU into multiple sequences we have a case of
streamed sequences.  Both PH and PLDA say that the SEQ_CNT should be
continuously increasing across the streamed sequences.  However, PLDA
says the FCP_RSP frame may optionally *not* be considered streamed (in
other words the SEQ_CNT of the FCP_RSP may optionally be  0 instead of
n+1).  This exception doesn't break PLDA because the initiator can
detect a missing sequence of Read Data by counting the number of
received bytes.

In FC-TAPE, however, we can have data overlay occur in the case of error
recovery.  This means counting the number of received bytes doesn't give
a conclusively answer.  Even when the new SRR extended link service is
used to specify a retransmission of the data starting at a specific RO,
the target has the option to adjust the starting point to fit its
requirements (something about compression engines only being able to
start at specific offsets).  The target may have transferred an extra 4K
in the retry, and an entire 4K sequence at the end of the transfer may
have been lost.  The obvious way to detect this is to require the
FCP_RSP sequence to have a continuously increasing SEQ_CNT.

Concern number two.  
This works on paper, but how many have initiator silicon which would
support this.  In other words, without relying upon counting received
byte counts, can we detect the following missing sequence?  Remember,
silicon with FCP assists usually strip off all of the FC header and only
provide the data up to the OS.  Most of today's disk targets always give
a Seq_Cnt of 0 on the FCP_RSP.

FCP_DATA IU: SeqID=01; Seq_Cnt=00
FCP_DATA IU: SeqID=01; Seq_Cnt=01
FCP_DATA IU: SeqID=01; Seq_Cnt=02
FCP_DATA IU: SeqID=01; Seq_Cnt=03

FCP_DATA IU: SeqID=02; Seq_Cnt=04
FCP_DATA IU: SeqID=02; Seq_Cnt=05
FCP_DATA IU: SeqID=02; Seq_Cnt=06
FCP_DATA IU: SeqID=02; Seq_Cnt=07

<SeqID=03 is LOST.  It would have contained frames with Seq_Cnt's of 8,
9, A, B>

FCP_RSP IU: SeqID=04; Seq_Cnt=0c

More information about the T10 mailing list