Re: StatSN and overlapped commands

[Julian Satran <julian@cs.haifa.ac.il>]

Black_David@emc.com wrote:

> Dave,
> 
> 
>>Put simply, is a SCSI task considered completed when status is returned to
>>the initiator, or when status is acknowledged via ExpStatSN?
> 
> 
> The former, in fact, SCSI considers the task complete when status is
> generated at the target.  See sections 7.3 and 7.6 of SAM-2; a completed
> task transitions to the "Ended" state and is removed from the task set.
> 
> ExpStatSN an iSCSI retransmission mechanism for SCSI status in case it
> didn't get through the first time.
> 
> 
>>This causes a difference in behavior for untagged SCSI 
>>commands.  Consider:
>>
>>Initiator: SCSI Command = Write: Attr = Untagged (0) : 
>>InitiatorTaskTag=5:
>>CmdSN=4: ExpStatSn = 3
>>Target:  R2T: InitiatorTaskTag = 5
>>Initiator: SCSI Data: Initiator Task Tag = 5
>>Target: SCSI Status = Good:  Initiator Task Tag = 5: StatSn = 3
>>Initiator: Scsi Command = Write: Attr = Untagged (0) : 
>>Initiator Task Tag
>>= 6: CmdSN=5: ExpStatSn = 3
>>.
>>.
>>(Somewhere down the line a scsi command with ExpStatSN of 4 
>>is sent, ACKing
>>the Status to ITT #5)
>>.
>>.
>>
>>Is this an overlapped command error, since the SCSI task is still
>>oustanding until the status is acknowledge?
>>Or -- is the SCSI command considered completed as soon as status is
>>attempted (much like the clearing of a Congingent Allegiance 
>>as soon as status is started to the host)?  That would mean that this is a
> 
> legal
> 
>>exchange.
> 
> 
> The latter - as described, I believe it's legal.
> 
> 
>>If so, does this cause problems with command recovery as
>>described in section 3.2.2.2 ?
> 
> 
> No, iSCSI at the target is retaining the SCSI status of the completed
> command for retransmission.  SCSI believes the command to be completed,
> and any retransmission request (e.g., Status SNACK) is not visible to
> SCSI at the target.  In this case "command recovery" does not execute
> any commands at the target; it just causes retransmission of the saved
> status.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> black_david@emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
My only caveat to this would be that an initiator that reuses the 
Initiator Task Tag but does not acknowledge the reception of the status 
by an ExpSataSN is definitely misbehaving.

The target should not consider it as an implicit ack (as intermetiate 
status PDUs may have been lost - it should reject the command that 
reuses the Initiator Task Tag.

That is not necesarily related to the way an initiator maps SCSI tags to 
iSCSI tags - it is specific to iSCSI expectations about tag reuse.

You correctly stated that an iSCSI tag should not be reused before it's 
status is acknowledged but violating this rule is an iSCSI protocol 
error and not a SCSI error (overlapped command).

Julo