Cluster-Wide Device Special Files; Naming Conventions For Lvm - HP -UX 11i Administrator's Manual

Legacy device files were the only type of mass storage device files in releases prior to HP-UX 1 1i
Version 3. They have hardware path information such as SCSI bus, target, and LUN encoded in
the device file name and minor number. For example, the legacy device file /dev/dsk/c3t2d0
represents the disk at card instance 3, target address 2, and lun address 0.
Persistent device files are not tied to the physical hardware path to a disk, but instead map to the
disk's unique worldwide identifier (WWID). Thus, the device file is unchanged if the disk is moved
from one interface to another, moved from one switch or hub port to another, or presented from
a different target port to the host. The name of a persistent device file follows a simpler naming
convention: /dev/disk/diskn, where n is the instance number assigned to the disk. Neither
the device file name nor the minor number contain any hardware path information.
In addition, if the disk has multiple hardware paths, it is represented by a single persistent device
file. Persistent device files transparently handle multipathed disks and supersede LVM's multipathing
functionality described in
If a disk has multiple hardware paths, which LVM refers to as pvlinks, the persistent device special
file acts as a single access point for all the links. I/O requests are distributed across all available
links by the mass storage stack, with a choice of load balancing algorithms. If a link fails, the mass
storage stack automatically disables the failed link and I/O continues on all remaining links. Any
failed or nonresponsive links are monitored, so that when a failed link recovers, it is automatically
and transparently reincorporated into any load balancing. New disks and links are also
automatically discovered and added to load balancing. If the disk's connectivity changes—addition,
removal, or modification of a link—applications using the persistent device file are not affected,
provided at least one link is still active. New disks are automatically discovered.
You can use either persistent or legacy device files for LVM disks. LVM recommends the use of
persistent device special files, because they support a greater variety of load balancing options.
To facilitate migration from legacy DSF to persistent DSF, HP provides the
/usr/contrib/bin/vgdsf script, which works for both root and non-root volume groups. For
more detail on the HP-UX 1 1i v3 mass storage stack, its new features (such as the persistent DSFs),
and their benefits, see The Next Generation Mass Storage, HP-UX 1 1i v3 White Paper on http://
www.hp.com/go/hpux-core-docs.
NOTE: To use LVM's alternate link functionality, you must use legacy device files, and disable
multipathing through those legacy device files, as described in
Redundancy Through Multipathing" (page

Cluster-wide Device Special Files

HP-UX 1 1i Version 3, September 2010 Release introduces the support of cluster-wide device special
files (cDSF) for nodes running with Serviceguard, A.1 1.20.
A cluster device special files provides a consistent set of device special 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 command. The cluster device special
files can be displayed using the io_cdsf_config command. See the Managing Serviceguard
Eighteenth Edition manual for more detail on cluster device special files

Naming Conventions for LVM

You must refer to LVM devices or volume groups by name when using them within HP SMH or with
HP-UX commands. By default, the LVM device files created by both HP SMH and HP-UX commands
follow a standard naming convention. However, you can choose customized names for volume
groups and logical volumes.
Physical Volume Names
Physical volumes are identified by their device file names, as follows:
"Increasing Hardware Path Redundancy Through Multipathing" (page
28).
"Increasing Hardware Path
LVM Device File Usage
28).
13