Subject: iSCSI: Check Condition and Residuals

From: [email-masked]
Date: Thu, 8 Aug 2002 11:22:47 -0400

I think Julian's point is that the use of sense data
vs. transport support to return residual counts for
CHECK CONDITION is in T10's domain to specify, and
we ought to leave it to T10, but warn implementers
that it would be wrong to assume that iSCSI residuals
will only show up when GOOD status is returned.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From: Luben Tuikov [mailto:[email-masked]]
> Sent: Wednesday, August 07, 2002 12:19 PM
> To: Julian Satran; [email-masked]; [email-masked]
> Subject: Re: iSCSI: plugfest4 issues
> 
> 
> Let's disect:
> 
> I wrote:
> > 
> > 
> > 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.
> 
> The only problem I see here is that one may wrongly
> interpret target/initiator. I meant iSCSI target,
> iSCSI initiator, i.e. the transport shouldn't
> peek inside the sense data and mess with SCSI.
> It SHOULD act as a transport only. 
> 
> > 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.
> 
> Well, since reporting residuals with CHECK CONDITION
> is already established as the residual being reported
> IN the body of the sense data, I cannot imagine
> that in the future when status is CHECK CONDITION
> then the residuals will be anywhere else BUT in the
> sense data.
>  
> > Also, a transport (iSCSI) shouldn't be influenced by
> > another transport (FCP), but only by the unifying layer,
> > i.e. SAM-3.
> 
> Well?
> 
> -- 
> Luben
>

---

From: Luben Tuikov <[email-masked]>
Date: Fri, 09 Aug 2002 10:11:38 -0400

> will only show up when GOOD status is returned.

And this is EXACTLY WHAT I'm saying.
Quoting myself here for n-th time:

`` I.e. the target SHOULD NOT look inside the sense data
   and retrieve them [residuals] (EXTENDED COPY exception). ''

This has been an absolute non-issue for me right in
the beginning with this:

Santosh Rao wrote (Thu, 01 Aug 2002 10:11:48 -0700):
> Julian & Robert [Russell],
>
> I raised the same query regarding RESID for FCP/FCP-2 this time last
> year. The response I got for FCP/FCP-2 was that RESID information shall
> be valid, regardless of the scsi status returned. The RESID field, can
> be checked by the scsi transport drivers independent of the SCSI STATUS.
THIS-------------------------------------->^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> I have enclosed the T10 response from Rob Snivelly below on that issue.
> As per FC-PLDA, the RESID information is valid, regardless of the scsi
> status returned by the device. 
>
> An example of this is the case of "NO SENSE" or "RECOVERED ERROR" check
> condition, when the data transfer may have taken place and a CHECK
> CONDITION is returned. Also, for other CHECK CONDITION status', partial
> data transfer may have taken place and hence, resid information should
> be present.

This alone is CLEARLY implying that targets look up the residuals
right in the sense data, which is totally wrong. (Repeating myself
here again.)

I don't know why this was brought up _at__all_.

The iSCSI document is as clear and complete as anything else
regarding residuals and NOTHING should be touched regarding
that matter. <- that's what I'm saying.

-- 
Luben

---

From: Santosh Rao <[email-masked]>
Date: Fri, 09 Aug 2002 11:43:40 -0700

> right in the sense data, which is totally wrong. (Repeating myself

My mail raised the question of when FCP-x initiator scsi transport
drivers can examine the resid field. This has nothing to do with
targets. I made no mention of targets peeking into sense data. 

Please read the complete mail properly in its full context before
arriving at conclusions.

- Santosh

---

From: Luben Tuikov <[email-masked]>
Date: Fri, 09 Aug 2002 15:45:46 -0400

> targets. I made no mention of targets peeking into sense data.

Be that as it may, BUT you _were__spilling_ it into iSCSI.

AND iSCSI is clear on that! Residuals are valid only when
the appropriate bit is set (o/O/u/U).

Also your mail _is_suggestive_ of peeking into the sense data,
since you mention that status should be irrelevant for residuals.
(Again spilling this into iSCSI!)

This has _always_ been and still is a NON-ISSUE for me.

Again, iSCSI is clear, and as complete on residuals as anything
else out there.

If anyone has a problem with this, they should raise the issue
with T10 for a poke at SAM and/or SPC (whatever _they_ decide).

-- 
Luben

---

From: Santosh Rao <[email-masked]>
Date: Fri, 09 Aug 2002 13:13:45 -0700

It sounds to me like there is a mis-understanding here on who owns the
"RESID" field. 

FCP-2 makes it clear that it is the FCP-2 SCSI LLP in the target that
should initialize this field based on FCP_DL and its state information
on the bytes transferred. IOW, this is a field owned by the scsi
transport and should be initialized/computed by the scsi transport. (See
FCP-2 Rev 07a Section 9.4.8).

It sounds like folks here are assuming the the SCSI device server is
going to provide this information to the iSCSI LLP layer in the target
and the iscsi target layer would then copy this information into the
Response PDU. 

It is upto the iSCSI layer to initialize the RESID field anytime a data
underflow or overflow condition occurs. Perhaps, the RESID field
definition should provide guidelines on how the iscsi target layer
should compute the RESID, as is done by FCP-2 Section 9.4.8.

- Santosh

-- 
Finish each day and be done with it.  You have done what you could; 
some blunders and absurdities have crept in; forget them as soon as 
you can. Tomorrow is a new day; you shall begin it serenely and 
with too high a spirit to be encumbered with your old nonsense.

---

From: Luben Tuikov <[email-masked]>
Date: Fri, 09 Aug 2002 17:50:50 -0400

> FCP-2 Rev 07a Section 9.4.8).

Saying ``owned by the scsi transport'' is incomplete. A number of players
may be interested in the residual count and can take action appropriately.
From the transport to the user app initiating the IO.

That is, residuals are not ``transport-exclusive''.

And so, iSCSI does the right thing by providing _mechanism_ to report
them, should there be any reported by the players underneath the
iSCSI Target.

But going as far as what you're suggesting may be too restrictive.
On top of that I don't see any problems with the way FCP-2 puts it.
As I said before we're at par with it.

> and the iscsi target layer would then copy this information into the

There is quite a few things you have to communicate _with_ BEFORE you get
to talk to the actual SCSI device server. _Anyone_ of those can set a residual
for any number of things. (See my original reply-post on residuals
in the thread ``Re: iSCSI: plugfest4 issues'' dated 
Tue, 30 Jul 2002 23:54:49 -0400.)
 
> underflow or overflow condition occurs.

Yes.

> Perhaps, the RESID field

iSCSI does specify enough. Nothing is needed. Matter closed.

-- 
Luben