Re: iSCSI: I/O (command) recovery

[Santosh Rao <santoshr@cup.hp.com>]

Matt,

This is a good write-up and clearly outlines the behaviour. Just a couple of
comments below.

Regards,
Santosh

Matt Wakeley wrote:

> 4- The target iSCSI sends the read data and status to the initiator, but does
> *not* deallocate the resources associated with the I/O.

The draft is ambiguous about (4). It states that the numbering MUST be supported,
but the data and status recovery MAY be supported. This means initiators
& targets MUST use StatSN/ExpStatSN. However, the target is allowed to
de-allocate the resources associated with the I/O without waiting for ExpStatSN
ack.


> If some error occurs such that the initiator iSCSI does not receive all the
> data and status, then the initiator iSCSI performs whatever
> link/connection/session recovery to re-establish communication with the
> target.  At that point, the initiator iSCSI layer re-issues the I/O with the
> retry bit set.
>
> - At this point, the target iSCSI layer (*not* the SCSI layer) recognizes the
> command is a duplicate (because the retry bit is set), and instead of sending

Again, the wording for the above in the draft could do with some clarity (Section
1.2.2.1). It is not clear from the draft whether CmdSNs that are outside the
(ExpCmdSN, MaxCmdSN) window are to be accepted if the retry bit is set.

My interpretation of :
 "- The target MUST silently ignore any command
     outside this range or duplicates within the range not flagged with
     the retry bit (the X bit in the opcode)."

is :
- ignore all commands outside the (ExpCmdSN, MaxCmdSN) range.
- ignore all duplicate commands within the range that are not flagged with the
   retry

So, if a command with the "retry" bit is set is received outside the (ExpCmdSN,
MaxCmdSN) window, this causes the target to drop the received retry. The wording
on this could do with further clarity.


>
> For a Target Write operation:
>
> 8- The target iSCSI sends the status to the initiator (and saves it in the
> iSCSI allocated resources for the I/O), but does *not* deallocate the
> resources associated with the I/O.

Same comment as given for (4) under read operation.



begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard