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

George Penokie gop at us.ibm.com
Mon Apr 6 07:07:55 PDT 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* George Penokie <gop at us.ibm.com>
*
---------------------- Forwarded by George Penokie/Rochester/IBM on 04/06/98
09:03 AM ---------------------------


gericson at clariion.com on 04/02/98 05:18:38 PM
Please respond to gericson at clariion.com
To: George Penokie/Rochester/IBM at ibmus
cc:
Subject: FW: RE: Question on Scope: 8-byte vs 2-byte LUNs
George,

We are down to two points for discussion. Feel free to post to
reflector, or we can work to agree and then post.
1. the one labeled F which refers to the use of 2-byte LUNs between
levels.
2. the one labeled G which refers to which LUNs are reported by
REPORT LUNS
As before, I won't copy the entire discussion, just the relevant
portions.

Number 2 is the easier issue. REPORT LUNS says that the command shall
return information about only those logical units to which commands may
be sent. In your tutorial you say: This example assumes that all the SCC
devices allow full access to all LUNs. I looked for a mechanism for an
application client to control whether or not an SCC device allows access
to underlying LUs within SCC, but didn't find it. More generally, my
preference would be for LUs that have been configured into a Redundancy
Group to be no longer directly accessible to the application client,
except through the SCC device. As a result, I would expect to see the
following responses from REPORT LUNS after the configuration steps in
your tutuorials.
REPORT LUNS(T3, L0000/0000/0000/0000) : To level 0 Target
* 0000/0000/0000/0000 : Level 0 Bus 0 target 3 SCC lun 0
* 4000/0000/0000/0000 : Level 0 Bus 0 target 3 Volume Set lun 4000

* 0201/0000/0000/0000 : Level 1 Bus 2 target 1 SCC lun 0
* 0201/0201/0000/0000 : Level 2 Bus 2 target 1 SCC lun 0
* 0201/0201/0201/0000 : Level 3 Bus 2 target 1 SCC lun 0
Note that LUs that have been configured into Redundancy Groups and then
Volume Sets don't show up because they are no longer directly
addressable.

REPORT LUNS(T3, L0201/0000/0000/0000) : To level 1 Target
* 0000/0000/0000/0000 : Level 1 Bus 0 target 1 SCC lun 0
* 4000/0000/0000/0000 : Level 1 Bus 0 target 1 Volume Set lun 4000

* 0201/0000/0000/0000 : Level 2 Bus 2 target 1 SCC lun 0
* 0201/0201/0000/0000 : Level 3 Bus 2 target 1 SCC lun 0
The level 2 and 3 Volume Sets are not directly accessible from level 1
because they are contained in the level 1 Volume Set.

REPORT LUNS(T3, L0201/0201/0000/0000) : To level 2 Target
* 0000/0000/0000/0000 : Level 2 Bus 0 target 1 SCC lun 0
* 4000/0000/0000/0000 : Level 2 Bus 0 target 1 Volume Set lun 4000

* 0201/0000/0000/0000 : Level 3 Bus 2 target 1 SCC lun 0


The level 3 Volume Set is not directly accessible from level 2 because
it is contained in the level 2 Volume Set.
REPORT LUNS(T3, L0201/0201/0201/0000) : To level 3 Target
* 0000/0000/0000/0000 : Level 3 Bus 0 target 1 SCC lun 0
* 4000/0000/0000/0000 ; Level 3 Bus 0 target 1 Volume Set lun 4000
Note that the original level 4 LUs are no longer visible....
Note that the bottom level volume set is defined in the address space of
the SCC device, not in the address space of the LUs that it is composed
of. This leads us back to the number 1 question, are 2 or 8 bytes
required in the SCC commands.

You said:


A) Volume sets are not really any different from disk drives
I agree
B) Goal of addressing method was to allow devices to be added into the
hierarchy without every device within the hierarchy having to know about
all other devices.
OK, lets make sure to preserve this.
C) This is done by giving each levels controlling device control over an
address space (i.e., two out of the eight bytes).


No, I read SCC/SPC/SAM to say that the 2-byte LUN address space
controlled by a controlling device is relative to the target containing
the controlling device, not a level.
D) If two SCC devices are at the same level under a single SCC device
then they would each have there own LUN.
For 8-byte LUNs, I agree. For 2-byte LUNS, then not necessarily.
Consider an SCC device (X) which has SCC devices (A) and (B) at the
level below it. (A) and (B) will have different 2-byte LUNs. However,
consider the case where (A) and (B) each have an SCC device at the next
lower level, call them (J) and (K) respectively. These two devices may
have the same 2-byte LUN. (A) has no control over (B)s choice of LUN for
(K) and vice versa.


E) If two SCC devices are at the same level under different SCC devices
(so in
effect they are sharing drives) then there is a good chance the drives
will
have the same LUNs (and even possibly the same target IDs if the top
level
devices are on separate buses). In this case keeping track of these
identical
addresses is the responsibility of the host (application client). The
standards
have attempted to help this situation by defining the worldwide IDs. By
using
those ID in addition to the target:LU addresses a host should be able to
determine all the information it needs about the mapping of a system.

I agree.
Back to F...) I do think the addressing works. Take a look at the
revised tutorial and see if
it helps.
I looked, it doesn't help with the problem that I spelled out. I'll
restate in more detail. Lets consider a system that looks like:
* L0, Bus 0
* Initiator Port 7
* Target Port 0
* LUN 0, Type SCCS
* L1, Bus 1
* Target Port 0
* LUN 0, Type SCCS
* L2, Bus 1
* Target Port 0, LUN 0, Type Disk
* Target Port 1, LUN 0, Type Disk
* L2, Bus 2
* Target Port 0, LUN 0, Type Disk
* Target Port 1, LUN 0, Type Disk
* L1, Bus 2
* Target Port 0
* LUN 0, Type SCCS
* L2, Bus 1
* Target Port 0, LUN 0, Type Disk
* Target Port 1, LUN 0, Type Disk
* L2, Bus 2
* Target Port 0, LUN 0, Type Disk
* Target Port 1, LUN 0, Type Disk
Lets configure four Volume Sets, as follows:
VS1 = Level(0), Target Port(0), LUN(0100/4000) contains
* Level(0), Target Port (0), LUN(0100/0100/0000/0000)
* Level(0), Target Port (0), LUN(0100/0101/0000/0000)

VS2 = Level(0), Target Port(0), LUN(0100/4001) contains
* Level(0), Target Port (0), LUN(0100/0200/0000/0000
* Level(0), Target Port (0), LUN(0100/0201/0000/0000)

VS3 = Level(0), Target Port(0), LUN(0200/4000) contains
* Level(0), Target Port (0), LUN(0200/0100/0000/0000)
* Level(0), Target Port (0), LUN(0200/0101/0000/0000)
VS4 = Level(0), Target Port(0), LUN(0200/4001) contains
* Level(0), Target Port (0), LUN(0200/0200/0000/0000)
* Level(0), Target Port (0), LUN(0200/0201/0000/0000)
Now the application client visible hierarchy that looks like:

* L0, Bus 0
* Initiator Port 7
* Target Port 0

* LUN 0, Type SCCS
* L1, Bus 1
* Target Port 0
* LUN 0, Type SCCS
* LUN 4000, Type Volume Set (VS1)
* LUN 4001, Type Volume Set (VS2)
* L1, Bus 2
* Target Port 0
* LUN 0, Type SCCS
* LUN 4000, Type Volume Set (VS3)
* LUN 4001, Type Volume Set (VS4)


Using 2-Byte LUNs, I don't see how to combine VS1 and VS3 into a single
LU called VS5. Combination is outside the scope of both the L1 SCC
devices and there is no unambiquous 2-byte name for the L0 SCC device to
use to identify both.
To solve this problem, I propose that the 2-byte LUNs used in SCC-2 to
expanded to be 8-byte LUNs. (This would also have the benefit of
allowing implementations maximum configuration flexibility under the
limits of the SCSI-3 architecture.)
Hope this helps to define the problem better.

Regards,
George Ericson
CLARiiON A Data General Corporation
Coslin Drive, MS-C44 Tel: 508 480-7349
Southboro, Ma. 01772 Fax: 508 480-7913





*
* 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