Subject: RE: ALUA/TPGS question
Date: Fri, 18 Aug 2006 11:15:46 +0100
From: "Banther, Michael" <michael.banther@hp.com>
To: <t10@t10.org>
X-Message-Number: 7169
Attachment #1: banther_michael.vcf

Ever since stumbling across ALUA, I've found the name 'unavailable
state' misleading.  The logical units visible through a port are not
really unavailable when that port is in the unavailable state.	Perhaps
a change to 'inoperative state' clarifies the intention of this state.
Regards,
Michael Banther
Hewlett-Packard Ltd.
+44 117 312 9503
-----Original Message-----
From: owner-t10@t10.org [mailto:owner-t10@t10.org] On Behalf Of Knight,
Frederick
Sent: 17 August 2006 19:53
To: t10@t10.org
Subject: ALUA/TPGS question
* From the T10 Reflector (t10@t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight@netapp.com>
*
I'm looking for further elaboration on some of the state information for
ALUA/TPGS support.  Section 5.8.2.4.5 (Unavailable state) of SPC4r6
implies you can communicate with the port - "When being access through a
target port in the unavailable target port asymmetric access state, the
device....."
If a target port is not logged into the fabric, is it "unavailable"?  Is
it in "unavailable" state?  Should that port be reported at all in the
REPORT TARGET PORT GROUPS data?  The port does exist on the device, and
it will normally (when logged in) always be in the same state as all
other ports in that group, but when not logged in, it is unavailable to
the host; should the host be told about it?
Section 5.8.2.1 has this definition - "A target port group is defined as
a set of target ports that are in the same target port asymmetric access
state at all times."
Since ports can be connected/logged into/out of the fabric
independently, if when logged out, they were reported as unavailable,
all the ports in that group would never be in that same state "at all
times", so every port would end up in a unique group (which seems to
defeat the whole purpose of TPGS).
So:
1) Should non-logged in ports be reported at all?
2) Do hosts want to know about ports that are not logged in now, but
might
	be logged in at a later time?
3) If hosts do want to know about non-logged in ports, what state are
those
	ports in?
4) If they are in unavailable state, is that an exception to the "same
state
	at all times" rule?  That ports in a group which is in the
"unavailable"
	state are allowed to transition to different groups when they
move out
	of the unavailable state (they move back into a group where they
will
	always be in the same state as all the other ports in that
group).
5) If hosts do want to know about non-logged in ports, should there be a
new
	state for those ports (an "unconnected" state)?
I believe the hosts do want to know about all ports on a device (even
those that are not yet connected to the fabric - it gives the host an
easy way to report what might be a H/W fault).	Therefore, I'd like to
write up a proposal for either #5 (a new "unconnected" state) or #4 (the
exception).
Does anyone have any suggestions on which to proceed with (or a pointer
to something I've missed in the spec that already covers this?).
	Fred Knight
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo@t10.org