Re: [Ips] iSCSI-specific unit attention conditions

"Knight, Frederick" <> Tue, 31 March 2009 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 887543A676A for <>; Tue, 31 Mar 2009 14:37:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.197
X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tIqKCqxlsXQx for <>; Tue, 31 Mar 2009 14:37:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6E4023A6997 for <>; Tue, 31 Mar 2009 14:37:46 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.39,304,1235980800"; d="scan'208";a="148438000"
Received: from ([]) by with ESMTP; 31 Mar 2009 14:38:46 -0700
Received: from ( []) by (8.13.1/8.13.1/NTAP-1.6) with ESMTP id n2VLckVr028553; Tue, 31 Mar 2009 14:38:46 -0700 (PDT)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 14:38:46 -0700
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 17:38:41 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 31 Mar 2009 17:38:12 -0400
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [Ips] iSCSI-specific unit attention conditions
Thread-Index: AcmyN3muVtch7cfqQ4mDSuvM/lOx5QAA7X3AAACnQHA=
From: "Knight, Frederick" <>
To: <>, <>
X-OriginalArrivalTime: 31 Mar 2009 21:38:41.0530 (UTC) FILETIME=[0F44E5A0:01C9B249]
Subject: Re: [Ips] iSCSI-specific unit attention conditions
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IP Storage <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Mar 2009 21:37:48 -0000

"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


-----Original Message-----
From: [] 
Sent: Tuesday, March 31, 2009 4:12 PM
To:; Knight, Frederick
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: [] On Behalf Of
Paul Koning
Sent: Tuesday, March 31, 2009 3:32 PM
Cc:; 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.


Ips mailing list