Re: [Ips] iSCSI-specific unit attention conditions

Julian Satran <> Sat, 04 April 2009 18:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 62E953A6A6D; Sat, 4 Apr 2009 11:15:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.44
X-Spam-Status: No, score=-5.44 tagged_above=-999 required=5 tests=[AWL=1.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6sCCyM7OjRBC; Sat, 4 Apr 2009 11:15:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 484DD3A6A06; Sat, 4 Apr 2009 11:15:31 -0700 (PDT)
Received: from ( []) by (8.13.1/8.13.1) with ESMTP id n34IGVtI010369; Sat, 4 Apr 2009 18:16:31 GMT
Received: from ( []) by (8.13.8/8.13.8/NCO v9.2) with ESMTP id n34IGVi83076342; Sat, 4 Apr 2009 20:16:31 +0200
Received: from (loopback []) by ( with ESMTP id n34IGVkL013433; Sat, 4 Apr 2009 20:16:31 +0200
Received: from ( []) by ( with ESMTP id n34IGVqP013430; Sat, 4 Apr 2009 20:16:31 +0200
In-Reply-To: <000001c9b4ee$a73e3da0$f5bab8e0$@com>
References: <> <> <> <> <000001c9b4ee$a73e3da0$f5bab8e0$@com>
MIME-Version: 1.0
X-KeepSent: 02E6844A:960EF36C-C225758E:0062068D; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5 December 05, 2008
From: Julian Satran <>
Message-ID: <>
Date: Sat, 4 Apr 2009 21:16:29 +0300
X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.0.1|February 07, 2008) at 04/04/2009 21:16:30, Serialize complete at 04/04/2009 21:16:30
Content-Type: multipart/alternative; boundary="=_alternative 0064605FC225758E_="
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: Sat, 04 Apr 2009 18:15:34 -0000 wrote on 04/04/2009 09:29:03:

> From:
> "Bill Galloway" <>;
> To:
> <>;
> Date:
> 04/04/2009 20:39
> Subject:
> Re: [Ips] iSCSI-specific unit attention conditions
> Sent by:
> This is a re-send from a different email.... 
> I am the guilty party associated with these sense codes.  I have been
> traveling for the last few days or I would have chimed in sooner.  My
> original proposal was not iSCSI specific.  It added three ASC/ASCQs 
> explain the intent better (IMHO).
> We produce an iSCSI target with many "Portal Groups" and "Network 
> Portal Groups come and go dynamically. Within a Portal Group, Network
> Portals come, go, or change dynamically.  The intent is for the 
initiator to
> be connected to all Network Portals, on all Portal Groups, all of the 
> This is usually accomplished with some combination of MCS in the 
> and a MPIO (multipath) layer above the initiator.  The initiator is
> perfectly willing to make all of these connections but there is no way
> specified in any standard to accomplish this task.  There is a mix of 
> here that makes for a messy solution.  I am certainly open to a better 
> The SCSI layer could care less about Network Portals coming, going, or
> changing but something has to kick the initiator to do a new discovery 
> make the appropriate connections.  This would have been better handled 
> the iSCSI layer but I could find nothing available.  In our 
> the MPIO layer traps these UAs and kicks the initiator.
> The SCSI layer does have a legitimate need to know about Portal Groups
> coming and going.  These map to SAM target ports and the SCSI layer may 
> to know. The initiator also needs to know so that it can make the new
> connections.  In our implementation the MPIO layer also traps these UAs 
> kicks the initiator.
> Why three codes? No good reason.  My first proposal was more generic 
> iSCSI and there was a hope that it would be useful to other protocols. 
> get the proposal passed, I agreed to change the names to be iSCSI 
> In retrospect when I made the name change, I could have dropped it to 
> code.  In our current implementation we treat all codes the same.
> I hope this explains the rational for these ASC/ASCQs.  I am not aware 
> anything in the iSCSI spec that accomplishes these goals. I am certainly
> willing to explain further and to work with STORM to document this 
> and/or come up with a better solution.
> Bill Galloway
> Pivot3, Inc.
> BillG[-at-]
> _______________________________________________
> Ips mailing list

The first reaction to your note would be probably that you are right - 
SCSI is probably the wrong layer to make initiators aware of the existence 
of a new port.
On the other hand any transport than has no "permanent session" (in a 
generic sense) would have a hard time handling it.
And even worse - if the target is connected through different transport to 
the same or different initiators which one of the transports should carry 
it (think only about a FCP target that has an iSCSI backup - a not 
entirely imaginary scenario)?

And the ugly part about doing it with UA is that you kick in a recovery 
process that might be non-trivial.

The cleanest solution (for iSCSI) is to relegate the discovery (and 
change) to an out of band mechanism (as I have advocated for a long time). 
The drawback is that all the available out-of-band mechanisms are heavy 
and quite expensive (this is not to be considered a critique - it is just 
a statement of fact). Alternatively we could choose to handle the iSCSI 
case exclusively and use a version of one of our messages to convey the 
change. It will not handle all the cases (as the above FCP - iSCSI mix) 
but will perhaps solve Bill's problem.

Alternatively we might try and persuade T10 (SCSI) do adopt an "in-band" 
mechanism to prompt (re) discovery that should not carry the UA weight in 
most of the cases and then make the codes obsolete if the cease to be 
useful and/or extend them to other transports.

The last alternative is to mandate that configuration changes of this type 
can be made only outside a session - that will require us to use only a 
change bit from session to session (or login key) to indicate a change or 
unknown state since last discovery.