Re: iscsi : changes involving tgt portal group tag.

[Paul Koning <ni1d@arrl.net>]

Apologies for the late followup, but this discussion has me puzzled.

Part of the concern appears to be around the worry that an initiator
might reconnect to "the wrong" port and as a result end up talking to
the wrong LU when it issues additional commands to a LUN it knows.

I don't understand how that's possible.  SAM-2 section 4.7.3 shows
that an LU is a component of a Device (not of a Port).  And 4.8 says
that a LUN "identifies the logical unit within a SCSI target device".

In other words, no matter what port you use to access a device, a
given LUN identifies the same LU in that device.

As for the rule in SAM-2 section 4.7.7 that a "port name shall never
change" and the conclusion that therefore a TPGT must be persistent, I
would ask "across what scope?" and "how would you tell"?

If I have an iSCSI device that at time T has a port named X, and at
time T+1 has a port named Y, how would I test whether the proposed
requirement has been implemented?  I think the answer is: if you can
see state you created, such as reservation state, but it's now
attached to a different port name, then that requirement has been
violated.  Conversely, whenever a target port has no state it needs to
remember (no reservations, no initiator-specific mode pages (iSCSI
section 2.4.3.1)) then it can disappear and a new target port can
appear in its place -- or equivalently, the port can simply change
its name, you can't tell the difference.

I guess what I'm getting at is this: a requirement for something to be
persistent has meaning only if there's state attached to that
persistent thing, state that you can observe.  What exactly is that
state and long must it be kept?  iSCSI 2.4.3.1 lists some (but it says
"e.g." so there might be other state?).  Without a complete list of
that state it's hard to figure out what the correct rule should be.

       paul