Message-ID: <3F308A68.6040309@haifasphere.co.il>
Date: Wed, 06 Aug 2003 07:56:08 +0300
From: Julian Satran <satran@haifasphere.co.il>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1
MIME-Version: 1.0
To: pat_thaler@agilent.com, ips@ece.cmu.edu
Subject: [Fwd: Re: StatSN and overlapped commands]
Content-Type: multipart/mixed;
 boundary="------------020108070206050502050106"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This is a multi-part message in MIME format.
--------------020108070206050502050106
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

To add to the previous note - keeping the status around is by itself a 
performance penalty but I read the question as being about recovery and 
you have to keep it around for recovery.

Julo

--------------020108070206050502050106
Content-Type: message/rfc822;
 name="Re: StatSN and overlapped commands"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Re: StatSN and overlapped commands"

Return-Path: <owner-ips-outgoing@ece.cmu.edu>
Received: from sos.ece.cmu.edu ([128.2.129.27]) by fep4.012.net.il
          with ESMTP id <20030806034855.DUFR6569.fep4@sos.ece.cmu.edu>
          for <satran@haifasphere.co.il>; Wed, 6 Aug 2003 06:48:55 +0300
Received: by sos.ece.cmu.edu (Postfix)
	id 2A16989F6; Tue,  5 Aug 2003 23:47:51 -0400 (EDT)
Delivered-To: ips-outgoing@sos.ece.cmu.edu
Received: from hazard.ece.cmu.edu (HAZARD.ECE.CMU.EDU [128.2.129.24])
	by sos.ece.cmu.edu (Postfix) with ESMTP id 0F76189F2
	for <ips-outgoing@sos.ece.cmu.edu>; Tue,  5 Aug 2003 23:47:51 -0400 (EDT)
Received: by hazard.ece.cmu.edu (Postfix)
	id D663211E; Tue,  5 Aug 2003 23:47:50 -0400 (EDT)
Delivered-To: ips-outgoing@ece.cmu.edu
Received: by hazard.ece.cmu.edu (Postfix, from userid 953)
	id AB25D13B; Tue,  5 Aug 2003 23:47:50 -0400 (EDT)
Received: from sos.ece.cmu.edu (SOS.ECE.CMU.EDU [128.2.129.27])
	by hazard.ece.cmu.edu (Postfix) with ESMTP id 85A3811E
	for <ips-outgoing@ece.cmu.edu>; Tue,  5 Aug 2003 23:47:47 -0400 (EDT)
Received: by sos.ece.cmu.edu (Postfix, from userid 363)
	id 72C2689FA; Tue,  5 Aug 2003 23:47:47 -0400 (EDT)
X-Original-To: ips@sos.ece.cmu.edu
Delivered-To: ips@sos.ece.cmu.edu
Received: from osgood.ece.cmu.edu (OSGOOD.ECE.CMU.EDU [128.2.129.25])
	by sos.ece.cmu.edu (Postfix) with ESMTP id 99AAB89F2
	for <ips@sos.ece.cmu.edu>; Tue,  5 Aug 2003 23:47:45 -0400 (EDT)
Received: by osgood.ece.cmu.edu (Postfix)
	id 6FAD184; Tue,  5 Aug 2003 23:47:45 -0400 (EDT)
Delivered-To: ips@ece.cmu.edu
Received: by osgood.ece.cmu.edu (Postfix, from userid 953)
	id 3A1B88F; Tue,  5 Aug 2003 23:47:45 -0400 (EDT)
Received: from fep2.012.net.il (fep2.012.net.il [212.117.129.202])
	by osgood.ece.cmu.edu (Postfix) with ESMTP id 2151A84
	for <ips@ece.cmu.edu>; Tue,  5 Aug 2003 23:47:41 -0400 (EDT)
Received: from haifasphere.co.il ([80.178.242.50]) by fep2.012.net.il
          with ESMTP id <20030806034739.BXNG2581.fep2@haifasphere.co.il>;
          Wed, 6 Aug 2003 06:47:39 +0300
Message-ID: <3F307A59.6050202@haifasphere.co.il>
Date: Wed, 06 Aug 2003 06:47:37 +0300
From: Julian Satran <satran@haifasphere.co.il>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: pat_thaler@agilent.com
Cc: julian@cs.haifa.ac.il, Black_David@emc.com,
	dcuddihy@attotech.com, ips@ece.cmu.edu
Subject: Re: StatSN and overlapped commands
References: <1BEBA5E8600DD4119A50009027AF54A0132E0486@axcs04.cos.agilent.com>
In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A0132E0486@axcs04.cos.agilent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk
X-Spam-Status: No, hits=-38.8 required=5.0
	tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
	      REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA
	autolearn=ham	version=2.50
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)

pat_thaler@agilent.com wrote:

> Julian,
> 
> I agree that the initiator is misbehaving, but I don't agree that the target should detect that misbehavior. The target SCSI layer thinks the command was done when it generated the status. As David said, the target keeps the status around so that it can resend it if requested by Status SNACK. It doesn't need to keep track of the tag anymore at that point.
> 
> If the target had to generate an error when a command came with for a tag before the status for a prior command with the same tag was acknowledged, then it would have to clear the memory of tags when status acks came in which is less efficient than doing it when posting the status.
> 
> Pat
> 
> -----Original Message-----
> From: Julian Satran [mailto:julian@cs.haifa.ac.il]
> Sent: Tuesday, August 05, 2003 10:56 AM
> <snip>
> 
>>
>>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
> 
Pat,

The target has to remember the status the status for recovery - if both 
I and T have agreed on recovery. If it drops it some recovery scenarios 
won't work.

You are right that when no recovery is agreed status can be dropped but 
not so if recovery is agreed. And while within connection recovery is 
not based on ITT a recovered status containing a wrong ITT is not a good 
idea!

Julo



--------------020108070206050502050106--