|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: iSCSI: plugfest4 issues
Julian,
Matching
FCP's wording resulted in a "go ask the expert" algorithm
for figuring
out what is required - we ought to do better, and this
is an iSCSI
protocol issue. What I'm looking for in 9.4 is:
- Bits 3-6
(o, u, O, U) MAY be set by the Target and SHOULD be checked
by the Initiator when the
Response is "Command Completed at Target"
no matter what the value of the
Status field is.
- SCSI
permits Residual Counts to be returned for Status values
other
than GOOD; see
[SPC2].
I believe
that both of these are implied by the current text, but
since
this caused
confusion at the plugfest, we ought to spell it out.
Thanks,
--David
--------------------------------------------------- David L.
Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA
01748 +1 (508)
249-6449 FAX:
+1 (508) 497-8018 black_david@emc.com
Mobile: +1 (978)
394-7754 ---------------------------------------------------
David,
We DO EXACTLY what FCP did - say
nothing. I went through the document -
thetre is no relation mentioned and that is what we do too.
In any case we cannot enforce a SCSI
behavior. The expectation is obvious
that if SCSI hands obver counts those will be carried by iSCSI.
I also suspect that the trouble may be
deeper than we think and I find it much more prudent to say nothing (again as FCP did).
Julo
| Black_David@emc.com
08/01/2002 05:56 PM
| To:
Julian Satran/Haifa/IBM@IBMIL cc:
ips@ece.cmu.edu Subject:
RE: iSCSI: plugfest4 issues
|
Julian, I think we need to do
something here, as there are clearly situations in which the residual count is important for commands
that complete with other than good
status, making the "other point of view" reported by Robert Russell incorrect. Waiting for SPC-3
to do something to clarify this
isn't going to do much for iSCSI interoperability in the short term. Since Bob Snively was
the Technical Editor of FCP-2, he
tends to be correct about what FCP-2 requires or intends - I suggest we follow FCP-2, and say that
the O/o/U/u bits are valid in all
cases (of course, if none of them are set, the Residual Count field is not valid). Thanks, --David
--------------------------------------------------- David L. Black,
Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA
01748 +1 (508) 249-6449 FAX:
+1 (508) 497-8018 black_david@emc.com Mobile: +1 (978)
394-7754 ---------------------------------------------------
-----Original Message----- From: Julian
Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, August 01,
2002 3:26 AM To: Santosh Rao Cc: IPS Reflector;
rdr@io.iol.unh.edu; Robert Snively; santoshr@hpcuhe.cup.hp.com; T10
Reflector Subject: Re: iSCSI: plugfest4 issues
Santosh,
I think that this behaviour should
be specified by SPC3. I looked (again) into the FCP docs and like iSCSI they
do not say anything beyond
iSCSI says. Like iSCSI they specify
that the field is valid when the Oo/Uu bits are set but nothing about how
those bits relate to status.
SPC says nothing about that either
(beyond that the bits set are not necessarily an indication of error).
Julo
| Santosh Rao
<santoshr@cup.hp.com> Sent by:
santoshr@hpcuhe.cup.hp.com
08/01/2002 03:44 AM
|
To:
IPS Reflector <ips@ece.cmu.edu>, Julian
Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu cc:
Robert Snively <rsnively@brocade.com>, T10 Reflector
<t10@t10.org>
Subject: Re: iSCSI: plugfest4
issues
|
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.
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.
It would be good to
maintain consistent behaviour across the scsi transports in this regard,
since protocol bridging from iscsi to FCP domain would expect RESID
information in the FCP domain, regardless of scsi status.
This also
allows scsi transports to remain free of SCSI command set details. (ex :
the scsi transport drivers do not need to parse for CHECK CONDITION or GOO
status
information.)
Thanks, Santosh
-------------------------------------------------------------------------
Subject:
Re: iSCSI: plugfest4 issues Date: Thu, 1 Aug 2002 02:52:19
+0300 From: "Julian Satran" <Julian_Satran@il.ibm.com> To:
"Robert D. Russell" <rdr@io.iol.unh.edu> CC:
ips@ece.cmu.edu
Bob,
Thanks - some comments in text.
Julo
"Robert D. Russell" <rdr@io.iol.unh.edu>
Julian:
Four issues came up today at the iSCSI plugfest:
1.
A question about whether or not the Residual Count field and
the appropriate O and U bits need to be computed on all SCSI
Response PDUs, regardless of the values in the Status and/or Response
fields.
One point of view says that the Residual Count field and the O
and U bits appear to be strictly iSCSI values that are derived by
the iSCSI target layer from the ExpectedDataTransferLength field of
the SCSI Command PDU and the DataSegmentLength fields of the DataIn
or DataOut PDUs sent as part of this command. Therefore ,the
iSCSI target always computes a Residual Count value without regard to
the Status and/or Response fields, since these are SCSI values.
The
other point of view says that the Residual Count field, and the O and U
bits, need only be set when the Status and Response fields indicate that
the command was completed at the target with a GOOD Status, and the target
does not have to compute or set the Residual Count field and the O or U
bits for other values of the Status and/or Response fields.
Which is
it? In any case, could this be clarified somewhere in the standard,
most likely in section 9.4.4.
+++ Residual count fields are in fact
carrioed over from the SCSI layer. I know that none of the SCSI docs
specifies exactly their behavior and it strikes me as a bad idea to have
protocols specify them. The values should be valid any time the target
decides to put them in. +++
------------------------------------------------------------------------- Subject:
RE: FCP_RSP Residual Checking. Date: Thu, 5 Jul 2001 13:18:42
-0700 From: Robert Snively <rsnively@brocade.com> To:
"'Santosh Rao'" <santoshr@cup.hp.com>,
T10 Reflector <t10@t10.org>,
Fibre Channel T11 reflector <fc@network.com>
Robert
Snively wrote: > > > Is the target required to
initialize the fields FCP_RESID_UNDER, > > FCP_RESID_OVER &
FCP_RESID when any I/O is completed > > without the data phase
having transferred exactly > > FCP_DL bytes, regardless of the
SCSI Status being returned ? > > > When the target
generates a CHECK CONDITION on an I/O > > and may have returned
less than FCP_DL bytes in the data > > phase for that I/O, is
it > > required to set the FCP_RESID_UNDER to 1 and indicate
the number of > > bytes not transferred in the FCP_RESID
field? > > The intent is that the answer to your second question
is: > FCP_RESID should appropriately regardless of the SCSI
Status > being returned. The classic errors of that class are
those > involving successful completion with reporting, like > the
"NO SENSE" and "RECOVERED ERROR" series of errors. > >
> > > What is the behaviour initiators can expect under the
above > > condition ? > > The intent is that there
be no conflict. I believe that FCP-2 > was a bit less bald than
FC-PLDA in stating the requirement. > > > Is there a
conflict in the behaviours described by FCP/FCP-2 > > &
FC-PLDA ? > > > > Bob Snively
e-mail:
rsnively@brocade.com > Brocade Communications Systems
phone: 408 487 8135 > 1745 Technology Drive > San
Jose, CA 95110 > > > -----Original Message----- >
> From: Santosh Rao [mailto:santoshr@cup.hp.com] > >
Sent: Thursday, July 05, 2001 12:15 PM > > To: T10
Reflector; Fibre Channel T11 reflector > > Subject: FCP_RSP
Residual Checking. > > > > > > All, >
> > > I've got a question on target behaviour while sending
a > > CHECK
CONDITION > > SCSI status in its FCP_RSP IU. >
> > > Is the target required to initialize the fields
FCP_RESID_UNDER, > > FCP_RESID_OVER & FCP_RESID when any
I/O is completed without the data > > phase having transferred
exactly FCP_DL bytes, regardless of the SCSI > > Status being
returned ? > > > > When the target generates a CHECK
CONDITION on an I/O and may have > > returned less than FCP_DL
bytes in the data phase for that I/O, is it > > required to set
the FCP_RESID_UNDER to 1 and indicate the number of > > bytes
not transferred in the FCP_RESID field? > > > >
FC-PLDA Section 8.2.4.1 states that : > > "SCSI targets
that transfer less than FCP_DL bytes during > > the
FCP_DATA > > IUs shall set the FCP_RESID_UNDER to 1". >
> > > No exceptions are specified in the case of a CHECK
CONDITION in the > > above definition, implying that FCP_RSP
residual checking can be > > performed irrespective of the SCSI
Status that was returned in the > > FCP_RSP. >
> > > However, the wording descriptions of
FCP_RESID_UNDER, > > FCP_RESID_OVER & > >
FCP_RESID in SCSI-FCP & FCP-2 are not as stringent as > >
FC-PLDA and do not > > mandate that FCP_RESID_UNDER shall
be set when the data > > transferred is < > >
FCP_DL. > > > > What is the behaviour initiators
can expect under the above > > condition ? > >
Is there a conflict in the behaviours described by FCP/FCP-2 >
> & FC-PLDA ? > > > > Thanks, >
> Santosh Rao > >
-- Education is when you read
the fine print. Experience is what you get if you don't.
Home
Last updated: Sat Aug 03 02:18:53 2002
11526 messages in chronological order
|