intro(7)intro(7)NAMEintro - introduction to device special files
DESCRIPTION
This section describes the device special files (DSFs) and hardware
paths used to access HP peripherals and device drivers. The names of
the entries are generally derived from the type of device being
described (disk, tape, terminal, and so on.), not the names of the
device special files or device drivers themselves. Characteristics of
both the hardware device and the corresponding HP-UX device driver are
discussed where applicable.
Device Types
Devices can be classified in two device access modes, and A raw or
character-mode device, such as a line printer, transfers data in an
unbuffered stream and uses a character device special file.
A block-mode device, as the name implies, transfers data in blocks by
means of the system's normal buffering mechanism. Block devices use
block device special files and may have a character device interface
too.
Device File Naming Convention
A device special file name becomes associated with a device when the
file is created, either automatically by the special file daemon or
explicitly with the or command. When creating device special files, it
is recommended that the following standard naming convention be used:
subdir An optional subdirectory for the device class (for
example, for raw device special files for disks, for
block device special files for disks, for raw tape
devices).
class The class of device, such as or
# The instance number assigned by the operating system
to the device. Each class of device has its own set
of instance numbers, so each combination of class and
instance number refers to exactly one device.
options Further qualifiers, such as disk partition tape den‐
sity selection for a tape device, or surface specifi‐
cation for magneto-optical media.
Naming conventions for each type of device are described in their
respective manpage entries.
Legacy mass storage device special files have a different naming con‐
vention that encodes the hardware path; this is described in the sec‐
tion.
Cluster Device Special Files
A cluster device special file provides a consistent set of device spe‐
cial files across a set of cluster nodes. The cluster device special
files of a LUN will be the same on any node in a specified set of nodes
that share the LUN.
The set of cluster nodes across which cluster device special files need
to be created can be specified using the cmsetdsfgroup(1M) command.
The cluster device special files can be displayed using the
io_cdsf_config(1M) command.
Cluster device special files are created in both block access mode and
raw (character) access mode. Block mode cluster device special files
are created in the directory, and character mode cluster device special
files are created in the directory.
Cluster device special file creation requires that Serviceguard A.11.20
be installed and patched with the cluster-wide device special file
(cDSF) enhancement, and possibly other dependent patches. See the lat‐
est version of the for more information.
Hardware Paths
Hardware path information, as well as class names and instance numbers,
can be derived from output; see ioscan(1M). There are three different
types of paths to a device: and All three are numeric strings of hard‐
ware components, notated sequentially from the system bus address to
the device address. Each number typically represents the location of a
hardware component on the path to the device.
The is composed of a series of bus-nexus addresses separated by slash
characters, leading to a host bus adapter (HBA). Beneath the HBA,
additional address elements are separated by period characters. All
the elements are represented in decimal. This is the format printed by
default by the command for most devices. An example of a legacy hard‐
ware path is
The is used for mass storage devices, also known as logical units
(LUNs). It is identical in format to a legacy hardware path, up to the
HBA. Beneath the HBA, additional elements are printed in hexadecimal.
The leading elements representing a transport-dependent target address,
and the final element is a LUN address, which is a 64-bit representa‐
tion of the LUN identifier reported by the target. This format is
printed by the command when the option is specified. The string is an
example of a lunpath hardware path.
Note that the address elements beneath the HBA may not correspond to
physical hardware addresses; instead, the lunpath hardware path should
be considered a handle, not a physical path to the device.
The is a virtualized path that can represent multiple hardware paths to
a single mass storage device. Instead of a series of bus-nexus
addresses leading to the HBA, there is a virtual bus-nexus (known as
the with an address of 64000. Addressing beneath that virtual root
node consists of a virtual bus address and a virtual LUN identifier,
delimited by slash characters. The string is an example of a LUN hard‐
ware path.
As a virtualized path, the LUN hardware path is only a handle to the
LUN, and does not represent the LUN's physical location; rather, it is
linked to the LUN's World Wide Identifier (WWID). Thus, it remains the
same if new physical paths to the device are added, if existing physi‐
cal paths are removed, or if any of the physical paths changes. This
LUN binding persists across reboots, but it is not guaranteed to per‐
sist across installations — that is, reinstalling a system or
installing an identically configured system may create a different set
of LUN hardware paths.
Device File Types (Mass Storage Devices)
Mass storage devices, such as disk devices and tape devices, have two
types of device files, device special files and device special files.
Both can be used to access the mass storage device independently, and
can coexist on the same system.
A device special file is associated with a LUN hardware path, and thus
transparently supports agile addressing and multipathing. In other
words, a persistent device special file is unchanged if the LUN is
moved from one HBA to another, moved from one switch/hub port to
another, presented via a different target port to the host, or config‐
ured with multiple hardware paths. Like the LUN hardware path, the
binding of device special file to device persists across reboots, but
is not guaranteed to persist across installations. The device special
file name follows the standard naming convention above, and the minor
number contains no hardware path information.
A device special file is locked to a particular physical hardware path,
and does not support agile addressing. Such a device special file con‐
tains hardware path information such as SCSI bus, target, and LUN in
the device file name and minor number. Specifically, the class and
instance portions of the device special file name indicate hardware
path information and are in the format as follows:
The instance number assigned by the operating system to the
interface card,
in decimal. It is a decimal number with a range of 0
to 255. There is no direct correlation between
instance number and physical slot number.
The target address on a remote bus (for example, SCSI address).
It is a decimal number with a typical range of 0 to
15.
The device unit number at the target address
(for example, the LUN in a SCSI device). It is a dec‐
imal number with a typical range of 0 to 7.
Note that the legacy naming convention supports a maximum of 256 exter‐
nal buses and a maximum of 32768 LUNs. Systems with mass storage
devices beyond those limits will be unable to address them using legacy
naming conventions.
Legacy device special files are deprecated, and their support will be
removed in a future release of HP-UX.
Viewing Mass Storage
With the advent of persistent and legacy device special files, commands
dealing with mass storage can choose between two of the I/O system. A
command presenting the view uses legacy device special files and legacy
hardware paths. The view uses persistent device special files, lunpath
hardware paths, and LUN hardware paths.
Depending on the command, both views may be presented, or the choice of
view may be controlled by a command option or an environment variable.
For example, the command shows the legacy view by default, and switches
to the agile view if the option is specified.
EXAMPLES
Example 1
The following is an example of a persistent device special file name:
where indicates block disk access and indicates device class and
instance number 3. The absence of indicates access to the entire disk;
see disk(7) for details.
Example 2
The following is an example of a legacy disk device special file name:
where indicates block disk access and indicates logical disk access at
interface card instance 0, target address 6, and unit 0. The indicates
access to section 2 of the disk.
Example 3
The following is an example of a persistent tape device special file
name:
where indicates raw magnetic tape, indicates tape device instance num‐
ber 4, and identifies the tape format as QIC150; see mt(7) for details.
Example 4
The following is an example of a cluster device special file name:
where indicates block cluster disk access and indicates device class
disk and instance number 5.
WARNINGS
The support of legacy device special files is deprecated and will be
removed in a future release of HP-UX.
SEE ALSOcmsetdsfgroup(1M), insf(1M), io_cdsf_config(1M)ioscan(1M), lssf(1M),
mksf(1M), mknod(1M), hier(5), introduction(9).
Manuals on the technical documentation website,
and
intro(7)