FC-TAPE: Lost Read Data Sequence detection

[Matt Wakeley]

* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Matt Wakeley <matt_wakeley at hp.com>
*
"Binford, Charles" wrote:

> 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.

Actually, the obvious way is to disallow data overlay in fc-tape,
just like in plda.  I understand why compression engines
may not be able to start at the address specified in the SRR.
However, it seems to me that the FC engine should be able to
discard the unwanted data, and start the sequence at the
specified RO.

-Matt Wakeley

(putting on flame suit in expectation of fiery attack from tape folks)

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