[Ips] lun reset and r2t error handling

Mike Christie <mchristi@redhat.com> Tue, 11 August 2009 20:57 UTC

Return-Path: <mchristi@redhat.com>
X-Original-To: ips@core3.amsl.com
Delivered-To: ips@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 164693A6BE4 for <ips@core3.amsl.com>; Tue, 11 Aug 2009 13:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.74
X-Spam-Status: No, score=-104.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id H1hdZEjCcCYN for <ips@core3.amsl.com>; Tue, 11 Aug 2009 13:57:06 -0700 (PDT)
Received: from mx2.redhat.com (mx2.redhat.com []) by core3.amsl.com (Postfix) with ESMTP id 54F443A6EA5 for <ips@ietf.org>; Tue, 11 Aug 2009 13:57:03 -0700 (PDT)
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com []) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n7BKuCdC021565; Tue, 11 Aug 2009 16:56:14 -0400
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com []) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n7BKuB1F004715; Tue, 11 Aug 2009 16:56:12 -0400
Received: from [] (vpn-12-226.rdu.redhat.com []) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n7BKuAvD002144; Tue, 11 Aug 2009 16:56:11 -0400
Message-ID: <4A81DAEA.8080403@redhat.com>
Date: Tue, 11 Aug 2009 15:56:10 -0500
From: Mike Christie <mchristi@redhat.com>
User-Agent: Thunderbird (X11/20090320)
MIME-Version: 1.0
To: ips@ietf.org, Hannes Reinecke <hare@suse.de>, open-iscsi <open-iscsi@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.58 on
Subject: [Ips] lun reset and r2t error handling
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ips>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2009 20:57:10 -0000


For a single connection session with ERL=0 and without FastAbort, if the 
initiator has sent a lun reset task management function and the target 
has sent a R2T, is it ok for the target to send a task management 
response with Function Complete, before the initiator has sent the 
data-out pdus for the R2T? It looks like the reason the target will do 
this is due to a internal target timeout (target did not get the 
data-outs within some timeout period).

If the target does return the task management function with Function 
Complete, should the initiator continue to respond to the R2Ts?

And one other question. In section 10.5.1, we have:

    The issuing initiator SHOULD however terminate (i.e., by setting the
    F-bit to 1) these response sequences as quickly as possible.

Does this mean if we have sent a lun reset, and the target has sent a 
R2T, should we be setting the F-bit in the continued data-out PDU so as 
to end the transfer, even though actual data transfer has not been 
completed entirely?

What if we do send all the data like normal, should that still be ok?