ALUA/TPGS question

Knight, Frederick 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 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 at t10.org



More information about the T10 mailing list