cam_resid calculation

James Smart USG smart at
Wed Jul 7 13:03:52 PDT 1999

* From the T10 Reflector (t10 at, posted by:
* James Smart USG <smart at>

I believe the general model on transfers is that they occur from "0" to "N"=
no gaps
in between. The only acceptable variation being if they stop somewhere in t=
in which case all data from "0" to the "stop" point being fully transfered =
the "stop"
point to "N" being untransfered. Other variations, although possible, are
usually to
complex to support.

As such, it doesn't really matter how the chunks in between "0" to "stop/N"=
in order, out of order, same data retransmit, etc as long as the basic mode=
above is
adhered to. If data between the "stop" point and "N" was sent and the trami=

protocol did not fully remove the effects of its transmission, then the i/o=
fail with
a error condition that indicates the state of the data transfer is unknown.=

Relative to your questions:
  a) Must the SIM set cam_resid ?    absolutely
  b) What does the application client do if it is non-zero ?  Depends on th=
        (typically the device class - disk/tape/etc). As you pointed out, d=
       are an all or nothing entity, while tapes may use the transfer to se=
       lengths, etc. Other device classes may have other uses/interpretatio=
   c) What are the relationships between the transfer length, the current d=
        pointer and the residual?
        Using the model above, is is easiest to answer the first and last:
        length is the N number of bytes that are expected to be sent; and
        is the tail portion, between "stop" and "N" that did not get sent.
        data pointer is not exported to the application client, and is simp=
ly a
        transmission specific entity used by the protocol chips to keep tra=
ck of

        where they are in the transfer. If the transmission protocol needs =
        the position, resend on the current position, jump to a new positio=
        it's all hidden from the application client. The client only sees t=
generic model.

-- James Smart

Gerard Roudier wrote:

> * From the T10 Reflector (t10 at, posted by:
> * Gerard Roudier <groudier at>
> *
> The CAM/CAM3 specifications seem to require SIMs to provide the residual
> count of an SCSI IO at completion.
> In usual situations, the calculation of this residual seems possible
> without too much complexity. But, in situations of a device using MODIFY
> DATA POINTER messages, such a calculation may get more complex. And if
> the residual applies to data that are not at the end of the buffer, this
> information may lose any relevance for the application client.
> My understanding of SPI is that the device may save, restore, change (if
> enabled for MDP) the data pointer at any time and so we can imagine lots
> of weird but compliant device behaviours that may complexify a lot the
> calculation of the residual count by the SIM.
> Looking into specifications that address SCSI devices, it seems that the
> 'residual' is mostly useless. In situation where it could help, as for
> stream devices when using variable length records, the actual number of
> bytes transferred can be obtained from the SENSE informations.
> As seen from the application client, the 'resid' is an information that
> addresses the data transferred to the device server that is returned by
> the transport layer. If we refer to SAM, this may appear as a layering
> violation, in my opinion.
> I apologize in advance for all my misunderstandings of the specs that are=

> very likely.
> My questions are:
> - Is the 'cam_resid' information required to be returned by SIM?
> - If yes, how the application client must behave when it is not zero?
> - What are the relationships between the transfer length, the current dat=
>   pointer and the residual?
>   For example, the SCSI specs does not preclude a device from restoring o=
>   changing the data pointer and then complete the IO. This is unlikely
>   to happen, obviously, but this must be considered, in my opinion.
> Thanks.
>         G=E9rard ROUDIER.
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at

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

More information about the T10 mailing list