ALUA/TPGS question

Knight, Frederick Frederick.Knight at
Thu Aug 17 11:52:48 PDT 2006

* From the T10 Reflector (t10 at, posted by:
* "Knight, Frederick" <Frederick.Knight at>
I'm looking for further elaboration on some of the state information for
ALUA/TPGS support.  Section (Unavailable state) of SPC4r6
you can communicate with the port - "When being access through a target
in the unavailable target port asymmetric access state, the device....."
If a target port is not logged into the fabric, is it "unavailable"?  Is
in "unavailable" state?  Should that port be reported at all in the
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;
the host be told about it?
Section has this definition - "A target port group is defined as
set of target ports that are in the same target port asymmetric access
at all times."
Since ports can be connected/logged into/out of the fabric
if when logged out, they were reported as unavailable, all the ports in
group would never be in that same state "at all times", so every port
end up in a unique group (which seems to defeat the whole purpose of
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
	be logged in at a later time?
3) If hosts do want to know about non-logged in ports, what state are
	ports in?
4) If they are in unavailable state, is that an exception to the "same
	at all times" rule?  That ports in a group which is in the
	state are allowed to transition to different groups when they
move out
	of the unavailable state (they move back into a group where they
	always be in the same state as all the other ports in that
5) If hosts do want to know about non-logged in ports, should there be a
	state for those ports (an "unconnected" state)?
I believe the hosts do want to know about all ports on a device (even
that are not yet connected to the fabric - it gives the host an easy way
report what might be a H/W fault).  Therefore, I'd like to write up a
for either #5 (a new "unconnected" state) or #4 (the exception).
Does anyone have any suggestions on which to proceed with (or a pointer
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 at

More information about the T10 mailing list