Proposal for Writable Device Identifiers
Tom Coughlan
coughlan at star.zko.dec.com
Thu Feb 5 06:14:20 PST 1998
* 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
devices 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
More information about the T10
mailing list