Subject: Re: iSCSI: plugfest4 issues

From: "Julian Satran" <[email-masked]>
Date: Wed, 7 Aug 2002 07:58:21 +0300

Luben,

You are in SCSI territory not iSCSI. This type of demands are for T10 (and 
I think you are wrong even there).

Julo

Luben Tuikov <[email-masked]>
Sent by: [email-masked]
08/07/2002 04:44 AM

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     [email-masked], [email-masked]
        Subject:        Re: iSCSI: plugfest4 issues

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

---

From: Luben Tuikov <[email-masked]>
Date: Wed, 07 Aug 2002 12:05:49 -0400

Julian Satran wrote:
> 
> Luben,
> 
> You are in SCSI territory not iSCSI. This type of demands are for T10 (and I think you are wrong
> even there).

What exactly do you mean?
Do you mind pointing it out?

-- 
Luben