Name that multi-port SCSI device

George M. Ericson GEricson at
Sat May 29 08:19:24 PDT 1999

* From the T10 Reflector (t10 at, posted by:
* "George M. Ericson" <GEricson at>

You and I are almost, but not quite in sync.  You and I agree on most of the
following, but I'm going to restate with some more complex examples, just to
make sure.  Following, I will discuss your tab(Xab,Yb) idea.

One key concept to watch for is distinquishing an implementation with the
model.  (For instance, two or more physical ports attached to one or more
cooperating processors might be modeled as a single multi-ported target, or
multiple targets (some may be multi-port) or as a target per processor.)
The point is that the implementation of Targets and LUs are somewhat
independent of the physical hardware.

I'm not sure from your comments below whether or not it is clear what my
position on multi-ported targets is with respect to Tab(X,Y).  (My position
is this is legal, and there are millions of real SCSI devices in the field
that implement it.)

Refining this.  (1) A Target may have one or more ports.
		    (2) An LU belongs to exactly one Target.

So lets take the example of a controller that has three physical ports (A,
B, and C) and three LUs (X, Y, and Z).  Now lets assume we want X and Y to
be visible through port A and port B of the controller and Y and Z to be
visible through port C.  The question becomes how many target devices must
be implemented on the controller to provide this picture.  One response is

Create Tab(X,Y) and Tc(Xa,Z).  So what about rule 2 above?  Doesn't X
violate it by being in both Tab and Tc?  My answer is no.  Because Xa is not
really the same thing as X.  In this example, we want to provide the
illusion that X is part of both.  So, we implement Xa to be simply a 1:1
mapping to X.  However, we could interpose additional behaviors on Xa that
are not part of X if we choose.  (For instance, the LUN for X and Xa may be
different.  Or, Xa may be read only.  Or, for idempotent devices, it may be
desirable for Xa to hide UAs created in X.)

One way to implement the techniques that I am describing is described in
SCC.  However, it should be clear that an implementation does not need to
expose the SCC command set, nor does it need to use Logical Unit virtual
device addressing as described in SAM to implement the model described.

So, one can stay within the boudaries of SAM-2.8 and yet still describe all
of the complex relationships between ports and LUs on a controller that have
been asked for.

Issue with tying Target to Hardware
Going back to your notation: I beleive that you would describe the above
example as
Tabc(Xabc,Yab,Zc).  The problem with that notation is that without
modifications to the rules for a target manager, a TARGET RESET received by
Tabc would be directed to X, Y and Z.  Take for example a TARGET RESET
issued through port C.  Without cooperation from other initiators, the
client would not see LU X through port C.  So, issuing a command that causes
an LU RESET on X would be an unintended side-affect.

There are probably lots of ways to correct this so that a TARGET RESET
through C only affects Y and Z.  My analysis so far leads me to assert that
all are equivalent to the solution that I've proposed using some number of
"virtual LU"s to preserve rule 2.

So, have I made the case?  Are there examples that the model does not cover?


-----Original Message-----
From: owner-t10 at Symbios.COM [mailto:owner-t10 at Symbios.COM]On Behalf Of
briandm at
Sent: Thursday, May 27, 1999 12:50 PM
To: GEricson at; briandm at; '-T10 Reflector'
Cc: roweber at
Subject: RE: Name that multi-port SCSI device

* From the T10 Reflector (t10 at, posted by:
* briandm at


I think I've figured out what I'm missing.  See below.
Please let me know if I've got it wrong.

On Thu, 27 May 1999 00:10:43 -0400, George M. Ericson wrote:
> Given: Port A and B attached to Target with LU X.  Initiator I attached
> to both port A and B. Initiator J attached only to port B.
Using your nomenclature of Tab signifying target with ports A and B (I hope
I'm using it correctly), I believe you would refer to this example as:

I consider this example to be similar to what I was describing but you
referred to my example to be something like:
Ta(X) Tb(X)
Ta(Xb) Tb(Xa)

I think I understand why now.  It's the complicating factor of not all LUs
being accessible through all ports.  If I toss in LU Y only accessible
through port B,  your example would become two targets:
Ta(X) Tb(Xa,Y)

My viewpoint is that there are one or more LUs associated with only one
target.  The target may have multiple ports.  The target optionally may be
configured (outside of the standards) to allow an individual LU to be
accessed or not accessed through a particular port.  If you'll allow me to
mangle your notation I view the modified example as Tab(Xab,Yb).

I believe your decomposition of my original example specifies the example as
being LUs, *each associated with one or more targets*, each target having
one port.  A target is defined as a set of accessible LUs.

I think we have a disagreement over how to view the mapping of LUs to
Although I too liked the earlier SAM-2 rev. multi-port section, it didn't
address this issue.


Get your free, private email at
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

* 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