Frederick.Knight at netapp.com
Thu Aug 17 11:52:48 PDT 2006
* 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 22.214.171.124.5 (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 126.96.36.199 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
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
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?).
* 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