Question on Scope: 8-byte vs 2-byte LUNs

George M. Ericson ericson at worldnet.att.net
Wed Mar 25 19:03:08 PST 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* "George M. Ericson" <ericson at worldnet.att.net>
*
This is a multi-part message in MIME format.

------=_NextPart_000_001A_01BD583C.74E3A540
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

George

Thanks for the info.  I think I understand the picture now.  However, I
didn't entirely follow your examples.
Are the following assertions correct?

    a.. Application client is at level 0, initiator port is at level 1, and
target LUs are at levels 1-4.
    b.. For an SCC command to a level n SCCS Logical Unit
        a.. SCC commands are unable to operate on LUs at lower (or higher)
levels than the SCCS LU.
        b.. The application client can directly send commands to LUs named
in 2-byte LUNs returned by an SCC command if the application client:
            a.. places the 2-byte LUN at level n in the 8-byte LUN
hierarchy, and
            b.. uses the same upper level (n-1) 2-byte LUNs as with the SCCS
LU.
    c.. For a REPORT LUNS command to a level n LU:
        a.. The LU processing the REPORT LUNS command will act as if it was
at level 1.
        b.. The returned 8-byte LUNs will always have the lower (n-1) level
LUNs filled with zeros.
        c.. The application client must shift the returned 8-byte LUNs by
(n-1) levels down and fill the upper level (n-1) 2-byte LUNs with the same
upper level (n-1) 2-byte LUNs used to address the LU that processed the
REPORT LUNS command.
    d.. For the COPY command you give several cases with the assumption that
the "Target" is doing the processing.
        a.. This doesn't match my understanding of SAM/SPC.
        b.. I'm expecting that the LU addressed by the COPY command will do
the processing (is the "copy manager") and that the source and destination
LUs may or may not be different from the copy manager LU.
        c.. The copy manager does not know what level it is at, so is never
in a position to manipulate the source or destination 8-byte LUNs based on
the copy manager's level.
        d.. Given this:
            a.. The application client must assume the responsibility of
casting the source and destination 8-byte LUNs into a form that can be
processed as if the copy manager, source, and destination LUs are all
connected via a common bus and that the copy manager can act as an initiator
on that bus and the source and destination LUNs will correctly address the
respective LUs when issued by the copy manager.  (In fact, the copy manager
will have to be rather clever to be able to know without some probing as to
whether or not either the source or destination LU is the same as the copy
manager LU.)
            b.. The above requirement implies that the application client
must shift up the source and destination 8-byte LUNs by (n-1) levels,
filling the lower (n-1) levels with zeros, where n is the level of the copy
manager LU.
            c.. This requirement says that a copy manager may only copy
between LUs at its level or lower (higher number).
Hope I've now got it.
Working though this has been helpful for me.
Thanks,
George Ericson

----------------------------------------------------------------------------
----

-----Original Message-----
From: owner-t10 at Symbios.COM [mailto:owner-t10 at Symbios.COM]On Behalf Of
George Penokie
Sent: Tuesday, March 24, 1998 6:00 PM
To: t10 at Symbios.COM
Subject: Re: Question on Scope: 8-byte vs 2-byte LUNs


George,
I will try to clear things up, but as you know, this is a complicated
subject.

1-This method was defined to allow all logical units to be addressed within
the
hierarchy regardless of the level they reside on, without the need for each
level having to know about every other level in the hierarchy. Using the
current method a level only needs to know about the devices that are
directly
attached to it. This allows an application client to issue (or pass though)
any
legal command to any logical unit even if it is at the lowest level of the
hierarchy without having to put the intermediate devices onto any special
pass
though mode. It also provides information on the structure of the hierarchy
(i.e., what is attached to what and the local target/LUN addresses). From
this
an application client can build a physical representation of the hierarchy
to
use for maintenance or for building configurations.


2-A REPORT LUNs command can only report LUNs attached to the target
receiving
the command. So a REPORT LUNs command sent to a device below level 0 can
only
report about the LUNs attached to it. It is recommended that REPORT LUNs
commands only be sent to level 0  devices unless the application client has
some special need for that information and can handle it properly.

3-The COPY command is indeed interesting using this structure but will work.
I
see four scenarios in which copy could be executed:

A-If the COPY command is between targets at level 0 then it is no different
than today. The target that receives the command becomes the initiator and
moves the data from it's selected logical unit to the selected target and
logical unit. The application client should setup the destination LUN
correctly
so the source target(initiator) can address the LUN without manipulation.

B-If the COPY command is between logical units attached to the target then
the
target can move the data between the logical units using standard reads and
writes.

C-If the COPY command is between logical units attached to the target and
the
target knows both those devices are attached to the same bus and support
COPY
it could reform the COPY to use the targets and LUNs those devices know
about
and reissue the command to one of those devices.

D-If the application client knows the devices it wants to copy data between
are
attached to the same bus in the hierarchy then it can route the COPY command
directly to the device it wants to be the source of the copy by directly
addressing that device. The structure of the hierarchy can be extracted by
the
application client by decoding the 8-byte LUN structure.

Hope this helps.
Bye for now,
George Penokie


owner-t10 at Symbios.COM on 03/20/98 11:53:16 PM
Please respond to ericson at worldnet.att.net @ internet
To: George Penokie/Rochester/IBM at ibmus
cc: t10 at Symbios.COM @ internet
Subject: Question on Scope: 8-byte vs 2-byte LUNs


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* "George M. Ericson" <ericson at worldnet.att.net>
*
This is a multi-part message in MIME format.
----------------------------------------------------------------------------
----
George,

Wonder if you (or others on T10) would clear up rules on how 8-byte and
2-byte LUNs are interpreted.

Some questions that SAM-2, SCC-2, or SPC-2 do not answer.
    1.. SCC-2 uses 2-byte LUNs in data structures.  Implies SCC-2 commands
are restricted to act on Logical Units at same level in the hierarchy as the
target Logical Unit.  So why did SCC-2 need to invent 8-byte 4 level LUNs?
    2.. On Report LUNs, 8-byte LUNs are returned.  How should they be formed
if the target Logical Unit is not at Level 1?  How does the target Logical
Unit know the path used to get to it?
    3.. Similarly, for a Copy command, if the target Logical Unit is not at
Level 1, how are 8-byte LUNs interpreted?  Is level n interpreted relative
to the level 0 initiator, the level n-1 initiator or the target?



----------------------------------------------------------------------------
----
One solution is that 8-byte LUNs are interpreted universally by all targets
within the same SCSI Domain.  It would be the responsibilty of each level to
recast any embedded LUN in a form that would preserve that semantic.  In
this scenario, the answers to 2 and 3 above is that the level 0 initiator
passes 8-byte LUNs that have consistent meaning to that initiator.  Lower
levels make appropriate transformations to achieve the semantics intended by
the upper layer.  If this solution is acceptable, then SCC-2 should also be
using 8-byte LUNs.  Since the use of 2-byte LUNs is restrictive in precisely
the place where the more complex 8-byte structure has value.

An alternative solution is that all commands are executed in the scope of
the level of the target Logical Unit.  In this case, the SCC-2 use of 2-byte
LUNs makes sense.  If this is the case, then shouldn't the copy and send
commands also use 2-byte LUNs?

Regards,
George Ericson
----------------------------------------------------------------------------
----

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com





------=_NextPart_000_001A_01BD583C.74E3A540
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">

 George Thanks for the info.  I = think I=20 understand the picture now.  However, I didn't entirely follow your = examples.
Are the following assertions correct?  Application client is at level 0, initiator port = is at=20 level 1, and target LUs are at levels 1-4. For an SCC command to a level n SCCS Logical=20 Unit SCC commands are unable to operate on LUs at = lower (or=20 higher) levels than the SCCS LU. The application client can directly send = commands to=20 LUs named in 2-byte LUNs returned by an SCC command if the = application=20 client: places the 2-byte LUN at level n in the = 8-byte LUN=20 hierarchy, and uses the same upper level (n-1) 2-byte = LUNs as with=20 the SCCS LU. For a REPORT LUNS command = to a level n=20 LU: The LU processing the REPORT LUNS = command will=20 act as if it was at level 1. The returned 8-byte LUNs will always have the = lower=20 (n-1) level LUNs filled with zeros. The application client must shift the = returned 8-byte=20 LUNs by (n-1) levels down and fill the upper level (n-1) 2-byte = LUNs=20 with the same upper level (n-1) 2-byte LUNs used to address the = LU that=20 processed the REPORT LUNS command. For the COPY command you give several = cases with the=20 assumption that the ;Target; is doing the processing. = This doesn't match my understanding of SAM/SPC. I'm expecting that the LU addressed by the COPY command will = do the=20 processing (is the ;copy manager;) and that the source = and=20 destination LUs may or may not be different from the copy = manager=20 LU.  The copy manager does not know what level it is at, so is = never in a=20 position to manipulate the source or destination 8-byte LUNs = based on=20 the copy manager's level.  Given this: The application client must assume the responsibility of = casting=20 the source and destination 8-byte LUNs into a form that can = be=20 processed as if the copy manager, source, and destination = LUs are=20 all connected via a common bus and that the copy manager can = act as=20 an initiator on that bus and the source and destination LUNs = will=20 correctly address the respective LUs when issued by the copy = manager.  (In fact, the copy manager will have to be = rather=20 clever to be able to know without some probing as to whether = or not=20 either the source or destination LU is the same as the copy = manager=20 LU.) The above requirement implies that the application = client must=20 shift up the source and destination 8-byte LUNs by (n-1) = levels,=20 filling the lower (n-1) levels with zeros, where n is the = level of=20 the copy manager LU. This requirement says that a copy manager may only copy = between=20 LUs at its level or lower (higher = number). Hope I've now got it.
 Working though this has been helpful for = me.
 Thanks,
George Ericson
 
-----Original Message-----
From: owner-t10 at Symbios.COM [mailto:owner-t10 at Symbios.COM]On Behalf Of
George=20 Penokie
Sent: Tuesday, March 24, 1998 6:00 PM
To:=20 t10 at Symbios.COM
Subject: Re: Question on Scope: 8-byte vs 2-byte=20 LUNs


George,
I will try to clear things up, but as you = know, this=20 is a complicated subject.

1-This method was defined to allow all = logical=20 units to be addressed within the
hierarchy regardless of the level = they=20 reside on, without the need for each
level having to know about every = other=20 level in the hierarchy. Using the
current method a level only needs = to know=20 about the devices that are directly
attached to it. This allows an=20 application client to issue (or pass though) any
legal command to any = logical=20 unit even if it is at the lowest level of the
hierarchy without = having to put=20 the intermediate devices onto any special pass
though mode. It also = provides=20 information on the structure of the hierarchy
(i.e., what is attached = to what=20 and the local target/LUN addresses). From this
an application client = can=20 build a physical representation of the hierarchy to
use for = maintenance or=20 for building configurations.


2-A REPORT LUNs command can only = report=20 LUNs attached to the target receiving
the command. So a REPORT LUNs = command=20 sent to a device below level 0 can only
report about the LUNs = attached to it.=20 It is recommended that REPORT LUNs
commands only be sent to level = 0 =20 devices unless the application client has
some special need for that=20 information and can handle it properly.

3-The COPY command is = indeed=20 interesting using this structure but will work. I
see four scenarios = in which=20 copy could be executed:

A-If the COPY command is between targets = at level=20 0 then it is no different
than today. The target that receives the = command=20 becomes the initiator and
moves the data from it's selected logical = unit to=20 the selected target and
logical unit. The application client should = setup the=20 destination LUN correctly
so the source target(initiator) can address = the LUN=20 without manipulation.

B-If the COPY command is between logical = units=20 attached to the target then the
target can move the data between the = logical=20 units using standard reads and
writes.

C-If the COPY command = is=20 between logical units attached to the target and the
target knows = both those=20 devices are attached to the same bus and support COPY
it could reform = the=20 COPY to use the targets and LUNs those devices know about
and reissue = the=20 command to one of those devices.

D-If the application client = knows the=20 devices it wants to copy data between are
attached to the same bus in = the=20 hierarchy then it can route the COPY command
directly to the device = it wants=20 to be the source of the copy by directly
addressing that device. The=20 structure of the hierarchy can be extracted by the
application client = by=20 decoding the 8-byte LUN structure.

Hope this helps.
Bye for=20 now,
George Penokie


owner-t10 at Symbios.COM on 03/20/98 = 11:53:16=20 PM
Please respond to ericson at worldnet.att.net @ internet
To: = George=20 Penokie/Rochester/IBM at ibmus
cc: t10 at Symbios.COM @ = internet
Subject:=20 Question on Scope: 8-byte vs 2-byte LUNs


* From the T10 = (formerly=20 SCSI) Reflector (t10 at symbios.com), posted by:
* ;George M. = Ericson;=20 <ericson at worldnet.att.net>
*
This is a multi-part message in = MIME=20 format.
--------------------------------------------------------------= ------------------
George,

Wonder=20 if you (or others on T10) would clear up rules on how 8-byte = and
2-byte LUNs=20 are interpreted.

Some questions that SAM-2, SCC-2, or SPC-2 do = not=20 answer.
    1.. SCC-2 uses 2-byte LUNs in data=20 structures.  Implies SCC-2 commands
are restricted to act on = Logical=20 Units at same level in the hierarchy as the
target Logical = Unit.  So why=20 did SCC-2 need to invent 8-byte 4 level LUNs?
    2.. = On=20 Report LUNs, 8-byte LUNs are returned.  How should they be = formed
if the=20 target Logical Unit is not at Level 1?  How does the target = Logical
Unit=20 know the path used to get to it?
    3.. Similarly, = for a Copy=20 command, if the target Logical Unit is not at
Level 1, how are 8-byte = LUNs=20 interpreted?  Is level n interpreted relative
to the level 0 = initiator,=20 the level n-1 initiator or the=20 target?



--------------------------------------------------= --------------------------
----
One=20 solution is that 8-byte LUNs are interpreted universally by all=20 targets
within the same SCSI Domain.  It would be the = responsibilty of=20 each level to
recast any embedded LUN in a form that would preserve = that=20 semantic.  In
this scenario, the answers to 2 and 3 above is = that the=20 level 0 initiator
passes 8-byte LUNs that have consistent meaning to = that=20 initiator.  Lower
levels make appropriate transformations to = achieve the=20 semantics intended by
the upper layer.  If this solution is = acceptable,=20 then SCC-2 should also be
using 8-byte LUNs.  Since the use of = 2-byte=20 LUNs is restrictive in precisely
the place where the more complex = 8-byte=20 structure has value.

An alternative solution is that all commands = are=20 executed in the scope of
the level of the target Logical Unit.  = In this=20 case, the SCC-2 use of 2-byte
LUNs makes sense.  If this is the = case,=20 then shouldn't the copy and send
commands also use 2-byte=20 LUNs?

Regards,
George=20 Ericson
--------------------------------------------------------------= ------------------

*
*=20 For T10 Reflector information, send a message with
* 'info t10' (no = quotes)=20 in the message body to=20 majordomo at symbios.com






------=_NextPart_000_001A_01BD583C.74E3A540--

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com





More information about the T10 mailing list