Re: [Ips] iSCSI-specific unit attention conditions
dcuddihy@attotech.com Wed, 01 April 2009 15:41 UTC
Return-Path: <dcuddihy@attotech.com>
X-Original-To: ips@core3.amsl.com
Delivered-To: ips@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6966A3A67F4 for <ips@core3.amsl.com>; Wed, 1 Apr 2009 08:41:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-J24Hd3muop for <ips@core3.amsl.com>; Wed, 1 Apr 2009 08:41:14 -0700 (PDT)
Received: from NOTESERV1.attotech.com (noteserv1.attotech.com [208.69.85.41]) by core3.amsl.com (Postfix) with ESMTP id BD74F3A63EB for <ips@ietf.org>; Wed, 1 Apr 2009 08:41:13 -0700 (PDT)
In-Reply-To: <AC32D7C72530234288643DD5F1435D530445C673@RTPMVEXC1-PRD.hq.netapp.com>
To: "Knight, Frederick" <Frederick.Knight@netapp.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006
Message-ID: <OFA0E4B8FE.959E8DA8-ON8525758B.00434BD9-8525758B.005642F2@attotech.com>
From: dcuddihy@attotech.com
Date: Wed, 01 Apr 2009 11:42:12 -0400
X-MIMETrack: Serialize by Router on NOTESERV1/SERV/ATTO(Release 7.0.3FP1|February 24, 2008) at 04/01/2009 11:42:14 AM, Serialize complete at 04/01/2009 11:42:14 AM
Content-Type: multipart/alternative; boundary="=_alternative 005642F08525758B_="
Cc: ips@ietf.org
Subject: Re: [Ips] iSCSI-specific unit attention conditions
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: Wed, 01 Apr 2009 15:41:15 -0000
It seems to me that the more important question is how useful these unit attention codes are. (For example, ATTO's Xtend San initiator doesn't make use of them.) If initiators don't care about this information, precisely defining these unit attention codes (instead of depricating them) will be a change for the worse. regards, david For every action there is an equal and opposite malfunction... David J Cuddihy Principal Engineer ATTO Technology, Inc. (716) 691-1999 x157 www.attotech.com Power Behind the Storage "Knight, Frederick" <Frederick.Knight@netapp.com> Sent by: ips-bounces@ietf.org 03/31/2009 05:39 PM To <brown_David1@emc.com>, <Paul_Koning@dell.com> cc ips@ietf.org, Black_David@emc.com Subject Re: [Ips] iSCSI-specific unit attention conditions "No commands are affected." The command which receives this response is NOT executed, and must be reissued by the initiator. True, no command other than the one that receives this response is affected. My guess from reading 05-406 is that the target is simply telling the initiator that it is time to reissue a SendTargets (redo discovery). My guess is that all 3 ASC/Qs would be handled by the host in the same way - something change (ala RSCN), so go find out what. I can't tell from the proposal why there needs to be 3 different reports (add/remove/change); it seems that "change" is really all that might be needed. So, it's possible my guess about the original intent is missing something. Fred -----Original Message----- From: brown_David1@emc.com [mailto:brown_David1@emc.com] Sent: Tuesday, March 31, 2009 4:12 PM To: Paul_Koning@dell.com; Knight, Frederick Cc: ips@ietf.org; Black_David@emc.com Subject: RE: [Ips] iSCSI-specific unit attention conditions Maybe this is obvious to the T10 folks in the audience, but . . . Since these unit attentions use an ASC of 3F, they indicate a change to the operating state of the device. No commands are affected. From the concise wording of the 05-406 proposal, it's hard to be sure what the author intended, but it sounds to me like the target is telling the initiator about a change in the membership of the portal group. Might be caused by a configuration change, possibly by hot-plugging another network interface card into the target system. DJ Brown -----Original Message----- From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of Paul Koning Sent: Tuesday, March 31, 2009 3:32 PM To: Frederick.Knight@netapp.com Cc: ips@ietf.org; Black, David Subject: Re: [Ips] iSCSI-specific unit attention conditions >>>>> "Frederick" == Frederick Knight <Knight> writes: Frederick> My interpretation of the "update" part of the agenda was Frederick> that SAM-4 was an example (and that we should also include Frederick> SAM-3 and SAM-5 as part of the update list). Therefore, Frederick> to add SPC to the update list is (in my opinion) within Frederick> the scope for the SCSI Update portion of this project. Frederick> Yes, it should be included in the charter (either Frederick> specifically, or by making clear the broader Frederick> interpretation of the "update"). Ok, that sounds good. Frederick> There is no person advocating these ASC/Q codes. These Frederick> are ALREADY APPROVED ASC/Q codes, and the person that Frederick> caused them to become approved is no longer part of T10, Frederick> nor is that company a part of T10 at this time, so it will Frederick> be hard to find them and get them to do anything. Frederick> In my opinion, we should define their use, and let the Frederick> e-mail reviews make sure we get it right (or as good as we Frederick> can). Partly because, contrary to the statement below, Frederick> the causes of all unit attention conditions are not Frederick> "clearly defined". I was assuming the person doing the advocating would be the appropriate one to do the defining. If that person isn't around but someone else wants to do the defining, that is fine, too. Part of what bothers me is that I can't fathom what these codes are intended for, or what the scenarios are when they might be generated, or what conclusion an initiator is supposed to draw when it sees one. The names vaguely suggest that they have something to do with asynchronous logout, but that is already fully covered in the iSCSI spec. Itdoesn't require any unit attentions in the first place, certainly not any iSCSI specific ones. I would rather see these things go away, unless there is a good argument made that there is something missing in iSCSI that needs to be added, and these codes are part of the solution. The fact that T10 already approved them isn't a reason to add them to iSCSI. paul _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list Ips@ietf.org https://www.ietf.org/mailman/listinfo/ips
- [Ips] iSCSI-specific unit attention conditions Black_David
- Re: [Ips] iSCSI-specific unit attention conditions Paul Koning
- Re: [Ips] iSCSI-specific unit attention conditions Black_David
- Re: [Ips] iSCSI-specific unit attention conditions Paul Koning
- Re: [Ips] iSCSI-specific unit attention conditions Paul Koning
- Re: [Ips] iSCSI-specific unit attention conditions brown_David1
- Re: [Ips] iSCSI-specific unit attention conditions Knight, Frederick
- Re: [Ips] iSCSI-specific unit attention conditions Knight, Frederick
- Re: [Ips] iSCSI-specific unit attention conditions dcuddihy
- Re: [Ips] iSCSI-specific unit attention conditions Paul Koning
- Re: [Ips] iSCSI-specific unit attention conditions Knight, Frederick
- Re: [Ips] iSCSI-specific unit attention conditions Kevin_Marks
- Re: [Ips] iSCSI-specific unit attention conditions Black_David
- Re: [Ips] iSCSI-specific unit attention conditions Bill Galloway
- Re: [Ips] iSCSI-specific unit attention conditions Julian Satran
- Re: [Ips] iSCSI-specific unit attention conditions Ralph Weber