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

George Penokie gop at us.ibm.com
Wed Apr 1 14:59:05 PST 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* George Penokie <gop at us.ibm.com>
*
George,
You are really keeping on my toes. And for awhile today I thought you had me
but I worked my through it, now if I can only relay my thoughts to you ;-}.
I have revised and corrected several errors in the tutorial based off your
comments and attached the new version. On to your comments:

A. I think we are in agreement (if you agree with the tutorial then we are OK).
B. Yes I agree.
C. Now I understand your comment and I agree.
D. Added in the SCC LUN.
E. I used a bad choice of words. I have changed non-SCC to hierarchical.
F. I have redone this section to show that volume sets are not really any
different than disk drives. The addressing method was especially developed to
allow devices to be added into the hierarchy without every device within the
hierarchy having to know about all other devices. This is done by giving each
levels controlling device control over an address space (i.e., two out of the
eight bytes).
If two SCC devices are at the same level under a single SCC device then they
would each have there own LUN.
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 do think the addressing works. Take a look at the revised tutorial and see if
it helps. I think we are getting closer.

G. I added in the other volumes to the LUN list.

Bye for now,
George Penokie

Note: The tutorial has been removed because it is too big for the reflector. If
you want a copy let me know.



gericson at clariion.com on 03/30/98 11:51:31 AM
Please respond to gericson at clariion.com
To: George Penokie/Rochester/IBM at ibmus
cc: t10 at symbios.com
Subject: Re: Question on Scope: 8-byte vs 2-byte LUNs


George,

Your tutorial does help.  Thanks.  Still have a few issues.  Rather than
replicate the entire thread, I'll just echo the relevant stuff.

A.  I asserted that for REPORT LUNS to level n, the returned 8-byte
LUNs will always have the lower (n-1) level LUNs filled with zeros.
You replied:
 Zeros are filled in if there are no devices at those levels.
Otherwise
 there should be a value if the SCC device allows commands to be
directed to
 them. See mini-tutorial for detailed example.
To not zero fill implies that there are levels greater than 4 allowed by
the architecture.

B. You said:
 If the copy manager is the SCC device it could move data between
buses if those buses are attached to it and controlled by it.
I agree.  And, (if I read SAM/SPC right), this also holds true if the
copy manager is not an SCC device.

C. I asserted that in a COPY command, 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.
You said that this wasn't clear.
Another way of saying this is that all LUNs intended to be used by the
copy manager must be made relative to the level of the copy manager.

I found your tutorial easy to follow.  I took the following notes as I
read it.

D. In section 1.1, you should have the REPORT LUNS command reporting the
addressed LU as well.

E. In section 2, you imply that non-SCC devices can not have multiple
levels.  In the current draft of SAM-2, SCC is an example of a device
type that can support multiple levels.  Also see the hisupport bit in
INQUIRE defined in SPC-2. (BTW, your example returns the value I
expected, see D above.)

F. In section 3, "Configuring a four level hierarchical SCSI system".
 In Step 1, you use SCC as defined to create a level 4 Volume Set
LU with a 2-byte LUN = VS1.  In Step 2, you use the level 4 2-byte LUN
for VS1 along side several level-3 2-byte LUNs.

 The problem with this approach is that the 2-byte LUN value for
level (n+1) LU is potentially not unique in the address space of a level
(n) LU.  There are two scenario's one is where there are multiple SCC
(or other ) devices under the level (n) LU each independently assigning
LUNs to their LUs.   The other is where the level (n) LU has already
assigned a LUN which duplicates a value assigned by level (n+1).  For
instance, assume in your example that VS1 was assigned 4000h and VS2 was
assigned 4001h.  Now assume that at a later time, more devices were
added to the level 4 device and we wanted to create a new Volume Set.
The most natural number to assign for this new level 4 LU would be 4001h
which would duplicate the level 3 value for VS2.

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.)   Under this proposal, VS1, VS2,
VS3, and VS4 would be defined as proposed in your example, however, they
would be addressed to their level.  For example, the list of LUs in step
1 would only change in that the lower levels would all be zero'd out.
In step 2, the new list would be  b1/t1:0000h:0000h:0000h,
b1/t2:0000h:0000h:0000h, and b2/t1:VS1:0000h:0000h.

G: In section 3.5.1: you stop reporting after one level.  Is this
because configuration hides the underlying LUs?


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