Re: iSCSI: error recovery

[julian_satran@il.ibm.com]

my comments are in text - Regards, Julo

"Mallikarjun C." <cbm@rose.hp.com> on 27/10/2000 03:59:05

Please respond to cbm@rose.hp.com

To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI: error recovery




>> At command restart it will resent what it has.
>
>No, command retry (restart) was meant to retry the whole I/O.  It was not
meant
>to be "send what you think I didn't get".

Yes, I agree.  This is the way I understand the spec as well.

Julian, could you please clarify the following:

o You stated that R2T is the exclusive means used by a target to
  request partial data xfers on retried writes.  How then is the CmdRN
  (would be DataRN) in a Write data payload used?  It seems redundant
  to me.
/<JS>
there is no DataRN on outgoing data
<JS>/
o Underflow, overflow and residual count in a SCSI response PDU
  must reflect the status taking into account the retry bit and
  the partial data xfers if any.  Is this a correct interpretaion?
/<JS>
The counts are not meant to represent data transferred on the wire
but rather end-to-end counts assuming that every "addressed byte" has been
transferred only once.

Obviously those counts have meaning only for storage devices not for
exoteric things like SCSI printers or plotters
<JS>/

>> Again, in the interests of simplicity, I request that data overlay be
>> forbidden.  Period.  Otherwise, the initiator would have to perform
score
>> boarding at the byte level to be positively sure that each byte was
really
>> received.
>> /<JS>
>> That is an interesting point.  I would argue that in the interest of
>> simplicity
>> we will stay neutral.  If we explicitly forbid it the every Initiator is
>> bound to check (enforce) it and that is a lot of work.  I assume we will
want
>> to
>> use SHOULD.  My point about scoreboarding is that initiators are not
required
>>
>> to check (enforce) the overlap.
>
>I disagree Julian.  Forbidding a target from performing a function does
not
>mandate that the initiator play policeman and verify that the target is
not
>doing what it's forbidden to do.
>
>If we do not forbid it, then the initiator will have to support it, and
that
>would be a lot of work.

I second Matt.  I would contend that even a target (supporting data
overlay)
complexity is significantly higher to keep track of the "net" amount of
data
that it sent out at any moment.  Data overlay only seems to increase
complexity
at either end in addition to consuming network bandwidth.
/<JS>
I did not say that I am supporting it either.
I am just against policing it.
And stating it with a MUST means that we have to provide error codes for
the cases in which it is not done properly.
Moreover this is not enforced by FCP or parallel SCSI
<JS>/
--
Mallikarjun
M/S 5601
Networked Storage Architecture
HP Storage Organization
Hewlett-Packard, Roseville.
cbm@rose.hp.com