michael.banther at hp.com
Fri Aug 18 03:15:46 PDT 2006
Attachment #1: <A HREF="r0608180_banther_michael.vcf">banther_michael.vcf</A>
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.
+44 117 312 9503
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Knight,
Sent: 17 August 2006 19:53
To: t10 at t10.org
Subject: ALUA/TPGS question
* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
I'm looking for further elaboration on some of the state information for
ALUA/TPGS support. Section 220.127.116.11.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
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 18.104.22.168 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).
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
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
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
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
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?).
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10