Alternative to: Proposal for Writable Device Identifiers

Ericson, George gericson at clariion.com
Fri Feb 6 07:25:35 PST 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* "Ericson, George" <gericson at clariion.com>
*
Tom, 

My comments to your proposal refer to SPC-2 and SCC-2 proposed
functionality.

To set your proposed identifier, there are already functions in SCC
called Report/Set_Peripheral_Device_Identifier.

On your proposal for a new type 4h to be used in the device identifier
page, I don't see how this is different from type 0h.  

I interpret (rash I know) Inquiry vital products data page to already be
defined to return identifiers set by Set_Peripheral_Device_Identifier as
type 0h.

I don't see a need to generate new mode select/sense pages for these.
The above commands are sufficient.

Two enhancements I would support in
Report/Set_Peripheral_Device_Identifier.
*	The ability to remove an identifier. 
		For instance, define bit 0 of byte 10 in the
Set_Peripheral_Device_Identifier command as delete.
*	The ability to set multiple identifiers.  
		For instance, 
*	define bit 2 of byte 10 in the Set_Peripheral_Device_Identifier
command as add_new.  Otherwise over-write first identifer.
*	define bit 0 of byte 10 of the
Report_Peripheral_Device_Identifier command as report_multiple.  If
report_multiple is set, the let bit 7 of byte 0 of the
Report_Peripheral_Device_Identifier parameter list be defined as
not_last.  Return as many identifiers as possible within the bounds
defined by Allocation length.

A corollary enhancement to Inquiry vital products data page is to
explicitely allow multiple identifiers of the same type to be returned.

Regards,
George Ericson

CLARiiON                              A Data General Corporation
Coslin Drive, MS-C44              Tel: 508 480-7349 
Southboro, Ma. 01772             Fax: 508 480-7913
   
>  
> >Date: Thu, 5 Feb 1998 09:14:20 -0500
> >From: coughlan at star.zko.dec.com (Tom Coughlan)
> >To: T10 at Symbios.COM
> >Subject: Proposal for Writable Device Identifiers
> >
> >* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted
> by:
> >* coughlan at star.zko.dec.com (Tom Coughlan)
> >*
> >     A proposal for writable device identifiers has been posted for
> review
> >     as document 98-112R0 on http://www.symbios.com/x3t10/doc98.htm.
> >     Please review this in preparation for the the March WG.
> >
> >     The first few sections of the document have been extracted and
> >     attached below to provide a summary of the proposal.
> >
> >     Tom Coughlan
> >     OpenVMS SCSI Project Leader
> >     Digital Equipment Corporation
> >     Nashua, New Hampshire
> >     tom.coughlan at digital.com
> >     603-884-0933
> >
> >     Subject:  Writable Device Identifiers
> >
> >     Summary
> >
> >     There is a requirement in some environments for the user to be
> able to
> >     write an identifier to a SCSI device.  This identifier is
> subsequently
> >     returned in the Device identification page of the Inquiry data.
> This
> >     functionality is provided by making two changes to the current
> >     standard, both in SPC-2:  1) define a new device identifier type
> >     value, to denote a user-written identifier, and 2) define a new
> mode
> >     page, to provide the application client with the means to set
> one or
> >     more device identifiers.  Implementation of the writable
> identifier is
> >     optional, and the mode page is optional for all device types.
> >
> >     Background
> >
> >     Many operating systems have traditionally assigned names to SCSI
> >     devices based on the path from the operating system (OS) to the
> >     device.  These naming schemes are convenient because they
> provide
> >     names that are unique, and they convey some information about
> the
> >     logical or physical location of the device.  Path-based names
> are
> >     problematic, however, when:
> >
> >     1.  there are multiple paths from an OS instance to the device
> >
> >     2.  there are multiple OS instances in the same naming domain
> with
> >         access to the same device (e.g.  a cluster)
> >
> >     3.  the interconnect employs path identifiers that are not as
> >         persistent as is required for OS device identification.
> Fibre
> >         Channel is one such interconnect.
> >
> >
> >     One solution to these problems is to devise a device naming
> scheme
> >     that is based on Word Wide Identifiers (WWIDs).  In such a
> scheme,
> >     each SCSI device is required to provide a persistent,
> >     path-independent, world-wide unique identifier in its Inquiry
> data.
> >     The operating system uses the WWID as the basis for device
> naming,
> >     thereby avoiding the problems with path-based naming listed
> above.
> >
> >     The WWID formats that are typically being implemented for SCSI
> are
> >     either 64-bit or 128-bit binary values.  These identifiers are
> too
> >     long to be usable by humans as device identifiers.  To resolve
> this
> >     difficulty, the OS (or a group of OS instances in a cluster)
> will
> >     typically assign a short alias to each WWID, and will present
> this to
> >     the user as the device name.  The OS is responsible for
> maintaining
> 
> >     the alias-to-WWID mapping in such a way as to provide the device
> >     naming consistency and persistence that is expected by the
> users.  For
> >     this discussion, we will assume that the OS implements a scheme
> for
> >     automatically assigning aliases to WWIDs, and that it implements
> a
> >     means for the user to modify aliases as desired to create
> meaningful
> >     device names.
> >
> >     The Problem
> >
> >     WWID-based naming does not work well in certain environments.
> For
> >     example:
> >
> >     1.  In many system installations, the individuals who replace
> failed
> >         storage devices do not have access to the operating system.
> This
> >         presents a problem when WWID-based naming is in use, because
> the
> >         replacement storage device will, by default, have a
> different OS
> >         device name.  The default OS name can be overridden, or OS
> >         parameters can be changed to compensate for the new name,
> but
> >         these actions require the involvement of personnel with
> different
> >         expertise, adding to the cost of the repair.
> >
> >     2.  Producers of turn-key systems desire to ship and maintain
> >         identical copies of the OS on identically-configured
> hardware
> >         systems.  This is not possible when WWID-based naming is in
> use,
> >         because the WWID-to-alias mapping on each system is
> necessarily
> >         different.
> >
> >     3.  In some installations it is necessary to boot different
> instances
> >         of an operating system at different times.  It is desirable
> for
> >         the device names in these environments to match.  This is
> >         difficult to achieve in general with WWID-based naming, and
> may be
> >         impossible in an environment where there is a read-only
> (CD-ROM)
> >         system disk.
> >
> >     4.  The default device name does not provide information about
> the
> >         location of the device.  New tools are needed to provide the
> user
> >         with a mapping from the default WWID-based device name to
> the
> >         device's logical or physical location within the
> configuration.
> >         These tools may not be available in the same timeframe as
> when
> >         path-independent device names are required.
> >
> >
> >     The Proposal
> >
> >     A variation on WWID-based naming is proposed to address the
> >     environments where the properties of WWID-based naming cause
> >     difficulties.  In the proposed scheme, each SCSI device
> optionally
> >     implements a writable, persistent, device identifier.  If the
> >     identifier is present, the SCSI device shall return it to the OS
> in
> >     the Device identification page of the Inquiry data.  A new
> identifier
> >     type shall be assigned to designate the user-supplied
> identifier.
> >
> >     SCSI devices that have a management interface, such as RAID
> >     controllers, may provide a means for the user to specify a
> device
> >     identifier for each logical SCSI device provided by the
> controller.
> >     Once defined, the device shall include the identifier in the
> Device
> >     identification page.
> >
> >     I addition, a standard method is required to allow an identifier
> to be
> >     written to the SCSI device, particularly for devices that do not
> have
> 
> >     a separate management interface.  This is accomplished via a new
> mode
> >     page.  The new mode page shall be optional, and shall be defined
> for
> >     all device types.  For ease of implementation, the format of the
> new
> >     mode page resembles the format of the Device identification
> page.  In
> >     typical applications, there would be just one identifier in the
> page,
> >     and the identifier would be short, because to the requirement
> for a
> >     human to be able to disambiguate it from others.
> >
> >     With these capabilities, it is possible to provide tools that
> can
> >     solve the problems described above.
> >
> >     Detailed Proposal
> >
> >     Please refer to 98-112R0 on
> http://www.symbios.com/x3t10/doc98.htm.
> >*
> >* For T10 Reflector information, send a message with
> >* 'info t10' (no quotes) in the message body to majordomo at symbios.com
> > 
> 
>     -----------------------------------------------------------------
>     Dave Ford             consulting to CLARiiON from -> Orca Systems
>     dford at clariion.com                                 dford at orca.com
>     508-480-7288                                         617-926-1399
*
* 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