Re: iSCSI: Check Condition and Residuals

[Luben Tuikov <luben@splentec.com>]

Santosh Rao wrote:
> 
> Luben Tuikov wrote:
> 
> > 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.)
> 
> 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.

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