FCP_RSP Residual Checking.

Robert Snively rsnively at Brocade.COM
Mon Jul 9 09:40:07 PDT 2001

* From the T10 Reflector (t10 at t10.org), posted by:
* Robert Snively <rsnively at brocade.com>

Close, I think.

>  * From the T10 Reflector (t10 at t10.org), posted by:
>  * "Pat LaVarre" <LAVARRE at iomega.com>
>  *
>  Aye, a maximally paranoid host will see as residue all of 
>  the data of any 
>  operation that glitches.  

All real glitches at the target should result in CHECK CONDITIONs
that tell what happened.  In most cases, the residue will not
be relevant, since what happened has nothing to do with the
residue.  In a few cases, usually also involving a residue in
the REQUEST SENSE data returned in the FCP_SNS_INFO field, the
residue may be used to verify that the amount transmitted and the
amount the target thought were transmitted were the same.

All real glitches in the protocol and link should turn up as 
errors or timeouts, recoverable using FCP-2 mechanisms or command
level retries.

FCP_RSP_INFO has some additional link protocol errors detected in
it, mostly related to software or hardware errors in the protocol.

Residues are usually honest differences of opinion between the
multiple layers of software supporting the disk or tape
device driver, the FCP transport mechanism, and the actual
target device, about how much data is to be transmitted.

>  No, nothing in the published texts 
>  requires hosts 
>  to be maximally paranoid.


>  Theory says some hosts save significant time by retrying 
>  only the residue ... 
>  but I've never seen this theory reconciled with the idea 
>  that glitches should 
>  be rare.

This is never the case.  The residue has to do with disagreements
about what was actually asked for.  It cannot indicate anything
about the validity of data that was transmitted or the possible
validity of data that was not transmitted.  In particular, it has
nothing to do with what write data was actually successfully 
written.  That must be extracted from FCP_SNS_INFO.


   a)	The hosts can never retry based on residue.  They must
	use CHECK CONDITION information.
   b) The residue errors are infrequent in most SCSI devices, but
	common in devices like tapes where requests often provide
      space for a maximum transfer, but the tape device knows
	better and offers only the available data, which is different
	in length.
   c) Residues in devices like disk drives (during normal read/write
	operations) are usually host driver stack
	discrepancies which may or may not be harmless.
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org

More information about the T10 mailing list