Proposal for IEEE company_id based formats for FC-PH world-wide identifiers
Larry Chen
larryc at maxstrat.com
Mon Jan 6 15:27:10 PST 1997
* From the SCSI Reflector (scsi at symbios.com), posted by:
* Larry Chen <larryc at maxstrat.com>
*
Hi Rod,
I agree that the LUN WWN is the primary name/entity for a SCSI driver.
I'm just looking for a reasonable anchor for the lun entities.
Given a set of luns, I want to anchor the luns down to the target device.
Personally, I don't care if the anchor is for a single controller or multiple
controller configuration (I really don't :) or is statically or dynamically
assigned. Though, the SCSI driver should re-probe after a hardware swap.
In SAM revision 18 object definition 5 (Target), the Task Manager is an entity
of the Target device, not a LUN. Also, there are situations when a SCSI driver
may want to serialize access to the Target device (not to the lun).
Below, I show the high level objects for a SCSI driver.
Notice, SVD_LUN has a back pointer to SVD_DISK.
typedef struct scsi_device {
SCSI_TASK_MGR scsi_device_task_mgr;
.
.
.
}SCSI_DEVICE;
/* Disk Node */
typedef struct svd_disk {
SCSI_DEVICE svd_base; /* base class */
SVD_LUN *svd_lun0; /* Pointer to Lun0 */
SVD_LUN *svd_other_luns; /* Pointer to Other Luns */
.
.
.
}SVD_DISK;
/* LUN Device Server */
typedef struct svd_lun {
SCSI_DISK *svd_disk; /* Back pointer */
.
.
.
} SVD_LUN;
On Mon, 06 Jan 97 16:37:00 CST DeKoning, Rod wrote:
>
>*
>* From the serial_solutions Reflector, posted by:
>* "DeKoning, Rod" <rdekonin at ppdpost.ks.symbios.com>
>*
>* To post to this Reflector, send email addressed to serial_solutions at zk3.dec.com
>*
>
>
>Larry,
>
>I do not believe that this strategy comes with a cost to the single
>controller case, nor does it make SCC mandatory.
>
>The direction set in the July meeting allows systems to cold swap or hot
>swap a device in BOTH single and dual controller configurations and continue
>to find the volume using the one handle that remains consistent through
>these swaps - the Logical Volume WWN.
>
>What you and Bob proposed is technically legal, I only wanted to illustrate
>why developers may not want to follow this course.
>
>We are currently at a cross roads where it is very important that OS driver
>writers understand the primary handle to use when discovering volumes is the
>volume LUN WWN. This is important to support both swapping and dual access
>pathing. I believe (and the group agreed in July) that statically
>configuring a node ID to a Volume LUN ID is setting the wrong direction.
>
>Perhaps you can enlighten me as to why it is so important to make this
>static designation instead of leaving it dynamic as previously discussed.
>
>
>Best Regards,
>
>Rod DeKoning
>Symbios Logic
>
>PS: With regards to your question concerning pg 13 of X3T11/96-467, I
>believe the statement is meant to state that for each transport flavor
>(parallel SCSI, FC-PH, 1394, etc.) you must provide an identifier that is
>appropriate. For example, the previous sentence indicated that IEEE 1394
>normally uses the EUI-64 format, FC-PH would use X3.203-1994. Bob, Please
>correct me if I am misinterpreting.
>
> ----------
>>From: scsi-owner
>>To: DeKoning, Rod
>>Cc: serial_solutions; scsi
>>Subject: RE: Proposal for IEEE company_id based formats for
>>FC-PH world-wide identifiers
>>Date: Monday, January 06, 1997 1:07PM
>>
>>* From the SCSI Reflector (scsi at symbios.com), posted by:
>>* Larry Chen <larryc at maxstrat.com>
>>*
>>Hi Rod,
>>
>>I too would like to see the multiple controller case supported by the
>>industry but
>>not at the expense of 1) the single controller case 2) making SCC mandatory
>>for all
>>RAID controllers.
>>
>>Note - I am neither agreeing or disagreeing with you in this email. Just
>>trying to
>>clarify something.
>>
>>Does your ideas adhere to the below statement made by document X311/96-467,
>>page 13 (of 22)?
>>
>>While more than one device identifier may be defined for a device and while
>>more
>>than one object may be identified within the device, at least one of the
>>identifiers
>>shall be the same value and format that is used by the transport medium.
>>
>>In the multiple controller case, what object will be used by both the
>>transport
>>medium and the SCSI level? Am I interpreting the above statement
>incorrectly?
>>
>>Regards,
>>Larry
>>
>>On Mon, 06 Jan 97 13:18:00 CST DeKoning, Rod wrote:
>>>
>>>*
>>>* From the serial_solutions Reflector, posted by:
>>>* "DeKoning, Rod" <rdekonin at ppdpost.ks.symbios.com>
>>>*
>>>* To post to this Reflector, send email addressed to
>>serial_solutions at zk3.dec.com
>>>*
>>>
>>>
>>>Larry, Mike, Bob, et.al.,
>>>
>>>Below, Larry discusses a mechanism to associate a controller (node) name
>to
>>>a Logical Unit. This concerns me (and possibly others?) for the following
>
>>>reasons.
>>>
>>>I went back to my personal notes for the July Serial Concerns Meeting to
>be
>>>sure we had discussed this point adequately, and I believe that we covered
>
>>>this topic in some detail. At that meeting, we discussed the fact that we
>
>>>wanted to purposely break the link between the Volume Logical Unit WWN and
>
>>>the Node Name of the device reporting the LUN's WWN. This is to ensure
>that
>>>we provide the following capabilities:
>>>
>>>1. Allow for dual controller environments in which the LUNs may be
>addressed
>>>from different controllers with different node IDs.
>>>2. Allow for hot swapping of devices used to access the LUNs.
>>>
>>>
>>>In the final analysis, (at least as I recall and recorded it) we are
>trying
>>>to encourage OS drivers and applications to avoid making a static link
>>>between a Volume Logical Unit and the device (controller) that is used to
>>>access the Volume Logical Unit. In general the OS drivers should be
>>>concerned with the WWN of the LUNs, and not the access devices since the
>>>data they are concerned with is associated with the LUNs and not the
>access
>>>device(s).
>>>
>>>Please let me know if this is not consistent with the July Serial Concerns
>
>>>discussion.
>>>
>>>Thanks,
>>>Rod D
>>>
>>>By the way, not linking the Logical Unit to the device is a key aspect to
>>>some of the changes we are proposing in the SCC2 model using the ASSIGN
>and
>>>DEASSIGN commands. These commands allow Volumes to be assigned or
>>>deassigned Logical Unit Numbers to different controllers connected to the
>>>same storage. To take advantage of such a capability, the system OS must
>be
>>>concerned first and foremost with the Volumes WWN, and only then, its
>>>physical path.
>>>
>>>
>>> ----------
>>>>From: Larry Chen
>>>>To: scsi; serial_solutions
>>>>Cc: Mike Wenzel
>>>>Subject: RE: Proposal for IEEE company_id based formats for
>>>>FC-PH world-wide identifiers
>>>>Date: Thursday, December 19, 1996 12:59PM
>>>>
>>>>
>>>>*
>>>>* From the serial_solutions Reflector, posted by:
>>>>* Larry Chen <larryc at maxstrat.com>
>>>>*
>>>>* To post to this Reflector, send email addressed to
>>>>serial_solutions at zk3.dec.com
>>>>*
>>>>
>>>>Hi Mike,
>>>>
>>>>Assume the following configuration:
>>>>
>>>>Host Computer <----FC-AL----> RAID controller + disk drives + enclosure
>>>>
>>>>The host computer is attached directly to the RAID controller only
>>>>(not the disk drives). The RAID controller will manage the disk drives
>>>>and export virtual LUNs to the host computer.
>>>>
>>>>At the SCSI initiator's side and level, I wanted a mechanism to associate
>
>>>the
>>>>virtual LUNs with its RAID controller. This mechanism would be general
>>>enough
>>>>to work for both the simple disk drive case and for the RAID case.
>>>>
>>>>Below, I will attempt to describe the entities at the FC and SCSI layers
>>>>for my current configuration.
>>>>
>>>>At the FC transport layer
>>>>-------------------------
>>>>Port entity is a SIM in CAM terminology.
>>>>
>>>>Node entity is the RAID controller (or more specifically,
>>>> the RAID controller's Field Replaceable Unit (FRU)).
>>>>
>>>>
>>>>At the SCSI layer
>>>>-----------------
>>>>LUN entity is a virtual LUN.
>>>>
>>>>RAID controller entity is the FRU.
>>>>
>>>>
>>>>
>>>>In my single RAID controller configuration, the FC Node entity and the
>>>>SCSI RAID controller entity are equivalent (and probably will have the
>same
>>>>value).
>>>>
>>>>Port name - any old WWN
>>>>Node name - IEEE Registered Format
>>>>Virtual LUN name - IEEE Registered Extended Format
>>>>RAID controller name - IEEE Registered Format
>>>>
>>>>and the association field could be used to associate the Virtual LUNs
>>>>with its RAID controller.
>>>>
>>>>A problem arises when multi-RAID controller complexes are introduced.
>>>>Now, the RAID controller entity is ambiguous (FRU vs. the virtual
>>>>RAID controller) and the FC Node entity and the SCSI RAID controller
>>>>entity are probably not the same.
>>>>
>>>>At this point, I will not be pursuing this matter any further (unless
>>>>someone is willing to stand-up with me).
>>>>
>>>>As an observation, RAID devices seem much more complex when compared to
>>>>the simple disk drive case. I hope the RAID Industry will form some
>>>>initiatives that will rectify this soon.
>>>>
>>>>Please call me if there are any further questions.
>>>>
>>>>Regards,
>>>>Larry
>>>>On Thu, 19 Dec 1996 11:27:42 -0800 Mike Wenzel wrote:
>>>>>Hi Larry,
>>>>>
>>>>>I agree with a previous post, the following description is too vague to
>>>>>really follow what is happening. Could you give a scenario, including
>the
>>>>>topology and node name of the controller and controlled device, then
>show
>>>>>what specifically would appear on the device's Device ID INQUIRY page
>>>>>(I assume that's what's involved) to correlate the devices? If you get
>>>time
>>>>>to do this, please post it to the broader distribution list: I'm shure a
>>>>>number of people were confused and that even more didn't really
>understand
>>>>>the scheme.
>>>>>
>>>>>Best Regards and Seasons' Greetings,
>>>>>
>>>>>Mike Wenzel
>>>>>mw at core.rose.hp.com
>>>>>
>>>>>>I was ready to go to Dallas and make a formal proposal but
>>>>>>fortunately, Bob Snively mentioned that I could use the
>>>>>>24-bit company_id and 36-bit Vendor Specified Identifier
>>>>>>fields from the virtual LUN's WWN in IEEE registered
>>>>>>extended format to get a pseudo WWN (60-bits only) for its RAID
>>>>>>controller node instead.
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>----------------------------------------------------
>>Larry Chen Tel: 408.383.1600 (x116)
>>MAXSTRAT Corporation Fax: 408.383.1616
>>801 Buckeye Court E-mail: larryc at maxstrat.com
>>Milpitas, CA 95035
>>----------------------------------------------------
>>
>>
>>
>>
>>*
>>* For SCSI Reflector information, send a message with
>>* 'info scsi' (no quotes) in the message body to majordomo at symbios.com
>>
>
----------------------------------------------------
Larry Chen Tel: 408.383.1600 (x116)
MAXSTRAT Corporation Fax: 408.383.1616
801 Buckeye Court E-mail: larryc at maxstrat.com
Milpitas, CA 95035
----------------------------------------------------
*
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com
More information about the T10
mailing list