cam_resid calculation

Gerard Roudier groudier at
Sun Jul 11 11:40:18 PDT 1999

* From the T10 Reflector (t10 at, posted by:
* Gerard Roudier <groudier at>

On Wed, 7 Jul 1999, James Smart USG wrote:

> * From the T10 Reflector (t10 at, posted by:
> * James Smart USG <smart at>
> *
> Gerard,
> I believe the general model on transfers is that they occur from "0" to "=
N" with
> no gaps
> in between. The only acceptable variation being if they stop somewhere in=
> middle,
> in which case all data from "0" to the "stop" point being fully transfere=
d and
> the "stop"
> point to "N" being untransfered. Other variations, although possible, are=

> usually to
> complex to support.

Indeed. It was my first statement, but with far less details, btw.

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

In the context of SPI, the point at which the transfer ended was the
current data pointer value reached at the end of the latest DATA phase
(hopefully followed by the STATUS phase).

What about the following wording from SPI-2 (modulo mistakes from me):
"Since the data pointer value may be modified by the target before the
task ends, it should not be used to test for actual data transfer length=20
because the value may no longer be valid".
Does it apply, even partially, to resid calculation?

> adhered to. If data between the "stop" point and "N" was sent and the tra=
> protocol did not fully remove the effects of its transmission, then the i=
/o must
> fail with
> a error condition that indicates the state of the data transfer is unknow=

I donnot understand what you mean here. Sorry.

Anyway, I have checked most of the specs that applied to SCSI devices and
didn't find any place where this information was required in order to
deal with transfers without errors.
In case of an error, hopefully reported by sense data, the residual must
not be used (I didn't find in the specs if this info was assumed valid=20
also in case of an error) by the application to calculate some amount of=20
data written to the medium, since the device may have pre-fetched data and =

experienced an error with some data not having been written to the
medium. Only the device can tell the application about the amount of data=20
written to the medium in case of an error, any getting it using some=20
layering violation is just wrong.

It seems to me that the SCSI specifications, except CAM, take care of the
residuals _not_ being useful. Could "residuals" be some antic, invented
when the SCSI model was not yet clean and that we donnot want to get rid
because of too many applications relying on it.

Anyway, any differentiation in the calculation of the "residuals" and on
the way applications may behave when it is not zero can only be a very bad
thing. For this reason, if "residuals" are required, then the expected
algorithm for its calculation should be documented in the specifications,
in my opinion.

Now, if applications just check the residual against zero in order to
check if the device is behaving correctly, this appears as a very weak =20
debugging information to me. A device that is just wrong in fetching=20
data is probably not usable at all.

> 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 =
> device
>         (typically the device class - disk/tape/etc). As you pointed out,=
> usually
>        are an all or nothing entity, while tapes may use the transfer to =
> block
>        lengths, etc. Other device classes may have other uses/interpretat=

It seems to me that we can deal with variable length blocks with tapes,
without using any residual returned by SIM, provided that we are using=20
appropriate options.

>    c) What are the relationships between the transfer length, the current=
>         pointer and the residual?
>         Using the model above, is is easiest to answer the first and last=
> Transfer
>         length is the N number of bytes that are expected to be sent; and=

> Residual
>         is the tail portion, between "stop" and "N" that did not get sent=
> Current
>         data pointer is not exported to the application client, and is si=
mply a
>         transmission specific entity used by the protocol chips to keep t=
rack of
>         where they are in the transfer. If the transmission protocol need=
s to
> reset
>         the position, resend on the current position, jump to a new posit=
> etc,
>         it's all hidden from the application client. The client only sees=
> generic model.

Hmmm... If the residual is required, it must also be provided to
application in case of MDP having been used in a way that left the current
pointer not at the end of the actually transferred data. In order to
achieve such a calculation, the SIM must maintain some map about the
chunks having been transferred between each MDP. The amount of data not
having been transferred can then accurately be calculated and returned to
the application. The problem is that this _complex_ process just may
inform the application about some zero/non-zero value. If the application
uses the resid value when it is non zero in such a situation to deduce
data that haven't been transferred, it may be _confused_ and mostly

Must a SIM panic the system when the "residual" value may confuse the
application and so may be reponsible of data loss or data corruption. ;-)=20


> -- 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 residua=
> > 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 MODIF=
> > 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, thi=
> > information may lose any relevance for the application client.
> >
> > My understanding of SPI is that the device may save, restore, change (i=
> > enabled for MDP) the data pointer at any time and so we can imagine lot=
> > 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 th=
> > '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 a=
> > 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 d=
> >   pointer and the residual?
> >   For example, the SCSI specs does not preclude a device from restoring=
> >   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

* 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