Re: iSCSI: plugfest4 issues

[Luben Tuikov <luben@splentec.com>]

Julian Satran wrote:
> 
> David,
> 
> the current text already says this but how about?
> 
> The Residual Count field MUST be valid in the case where either the U bit or the O bit is set. If
> neither bit is set, the Residual Count field is reserved. Targets may set the residual count and
> initiators may use it when the response code is "completed at target" (even if the status returned
> is not GOOD). If the O bit is set, the Residual Count indicates the number of bytes that were not
> transferred because the initiator's Expected Data Transfer Length was not sufficient. If the U bit
> is set, the Residual Count indicates the number of bytes that were not transferred out of the
> number of bytes expected to be transferred.
> 

I don't see any problems with the residual counts
and the overflow/underflow bits.

The text above is logically equivalent to the meaning
of the current draft.

I also looked at FCP (back when all this started)
and we're at par with it.

I'd only note that when status is CHECK CONDITION
(respoinse = CCT), then residuals SHOULD NOT be set.
I.e. the target SHOULD NOT look inside the sense data
and retrieve them (EXTENDED COPY exception).
This is the responsibility of the ULP at the initiator.

As to the future, I cannot imagine a CHECK CONDITION
status and residuals reported by any other means
than the already established (inside the sense data).
So this condition is as strong as MUST, but should
be left as SHOULD NOT, and probably not mentioned at
all, as is the current matter.

But this is in agreement with the current target spec
as per iSCSI, so no change is needed.

Also, a transport (iSCSI) shouldn't be influenced by
another transport (FCP), but only by the unifying layer,
i.e. SAM-3.

-- 
Luben