Can one LU be in multiple devices?

Paul von Behren Paul.Vonbehren at
Tue Sep 28 19:20:21 PDT 2004

* From the T10 Reflector (t10 at, posted by:
* Paul von Behren <Paul.Vonbehren at Sun.COM>
As a developer of storage management software (and storage
management software standards), I believe that it would be a
*bad* idea to allow an LU to be visible through multiple SCSI
devices as a general rule.  I believe that earlier in this thread,
multipath and LUN masking were mentioned as special cases
that touch on this issue.  I see these as acceptable, but
other multi-device LU configs seem unacceptable to me.

But here's my opinion of a couple scenarios that should be allowed
and a cases that should not.

1) Multipath is a good thing :-)  We want to allow an LU to be
accessible through multiple paths - even paths with multiple
protocols (e.g. FC and iSCSI).

2) Virtual views are good.  This includes LUN Masking as typically
provided by FC RAID arrays - different initiators see different
LU inventories (by issuing REPORT LUNS and INQUIRY and looking
at peripheral qualifiers).  From what I've read, it appears
that iSCSI allows multiple nodes on a target to also provide
virtual views.

What I think would be bad is for it to appear that two unrelated
targets each contained the same LU.  I think this would confuse
management software.  Customers want to be able to associate
logical resources (like LUs) with an asset - i.e. LUs show up
in a GUI as little boxes inside a big box that represent the
array, tape library, etc that they just spent a zillion dollars
purchasing.  I think we want to avoid having an LU that seems to
be part of two separate "big boxes".

Virtual views are more constrained.  I'll spare you the ASCII art
(I'm famous in SNIA for ASCII UML), but here's how I envision
acceptable joint custody of LUs.   With multiple virtual views,
there is still one big box (for the array), there's a bunch of
little boxes (LUs) and there's a Venn diagram within the big box
- allowing individual LUs to be part of different ovals representing
the virtual views.  And these ovals may also include all or a subset
of the target ports - allowing multipath access.

I think it would be useful for the emerging definitions and UML to
reflect all these objects.  I believe the big box corresponds to a
SCSI target device.  LUs and ports are well defined now.  That
leaves ovals.  I view these as something different from a SCSI
device.  In FC, we never named these ovals.  With LUN Masking, they
correspond to the LU inventory I mentioned above.  iSCSI target
Nodes seem to be pretty close.  But I think it would be useful
if there was a transport-independent, SCSI definition of virtual

If it would be helpful, I can create real UML - and/or the
big-box/little-box/venn-diagram I described above.


Mallikarjun C. wrote:

> * From the T10 Reflector (t10 at, posted by:
> * "Mallikarjun C." <cbm at>
> *
> Hi George,
> Thanks for the response.
> Some of us think (myself included) that it is desireable in future to 
> explicitly allow an LU to be visible through multiple SCSI devices. 
> Eventhough SAM-3 disallows it as you confirmed, SAM-4 could allow it in 
> the new UML drawings.  I do not see doing so affecting the currently 
> defined composition of an LU (device server, WWN etc.), but I may not be 
> seeing the big picture.  I would like to know more about the issues you 
> see in allowing multi-device visibility of an LU in SAM-4.
> Regards.
* 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