HP-UX System Administrator's Guide: Logical Volume Management (762803-001, March 2014)

link) information. The multipathed disk has a single persistent DSF regardless of the number of
physical paths to it. The legacy view, represented by the legacy DSF, continue to exist.
1.5.1 Legacy device files versus persistent device files
As of HP-UX 11i Version 3, disk devices can be represented by two different types of device files
in the /dev directory, legacy and persistent.
Legacy device files were the only type of mass storage device files in releases prior to HP-UX 11i
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 “Increasing Hardware Path Redundancy Through Multipathing” (page 31).
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 11i v3 mass storage stack, its new features (such as the persistent DSFs),
and their benefits, see The Next Generation Mass Storage, HP-UX 11i 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 “Increasing Hardware Path
Redundancy Through Multipathing” (page 31).
1.5.2 Cluster-wide Device Special Files
HP-UX 11i Version 3, September 2010 Release introduces the support of cluster-wide device special
files (cDSF) for nodes running with Serviceguard, A.11.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
16 Introduction