James Smart USG
smart at zk3.dec.com
Wed Jul 7 13:03:52 PDT 1999
* From the T10 Reflector (t10 at symbios.com), posted by:
* James Smart USG <smart at zk3.dec.com>
I believe the general model on transfers is that they occur from "0" to "N"=
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 =
point to "N" being untransfered. Other variations, although possible, are
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=
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=
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=
transmission specific entity used by the protocol chips to keep tra=
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=
-- James Smart
Gerard Roudier wrote:
> * From the T10 Reflector (t10 at symbios.com), posted by:
> * Gerard Roudier <groudier at club-internet.fr>
> 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.
> G=E9rard ROUDIER.
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at symbios.com
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com
More information about the T10