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