|HP-UX Reference > Introduction
intro(7)HP-UX 11i Version 3: February 2007
intro — introduction to device special files
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.
Devices can be classified in two device access modes, raw and block. 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 sfd, or explicitly with the insf, mknod, or mksf command. When creating device special files, it is recommended that the following standard naming convention be used:
Naming conventions for each type of device are described in their respective manpage entries.
Legacy mass storage device special files have a different naming convention that encodes the hardware path; this is described in the Device File Types (Mass Storage Devices) section.
Hardware path information, as well as class names and instance numbers, can be derived from ioscan output; see ioscan(1M). There are three different types of paths to a device: legacy hardware path, lunpath hardware path, and LUN hardware path. All three are numeric strings of hardware 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 legacy hardware path 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 ioscan command for most devices. An example of a legacy hardware path is 0/0/2/0.1.7.0.
The lunpath hardware path 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 representation of the LUN identifier reported by the target. This format is printed by the ioscan command when the -N option is specified. The string 0/2/1/0.0x50001fe1500170ac.0x4017000000000000 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 LUN hardware path 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 virtual root node) 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 64000/0xfa00/0x22 is an example of a LUN hardware 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 physical paths are removed, or if any of the physical paths changes. This LUN binding persists across reboots, but it is not guaranteed to persist 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, persistent device special files and legacy device special files. Both can be used to access the mass storage device independently, and can coexist on the same system.
A persistent 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 configured 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 legacy device special file is locked to a particular physical hardware path, and does not support agile addressing. Such a device special file contains 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 c#t#d# as follows:
Note that the legacy naming convention supports a maximum of 256 external 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 views of the I/O system. A command presenting the legacy view uses legacy device special files and legacy hardware paths. The agile 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 ioscan command shows the legacy view by default, and switches to the agile view if the -N option is specified.
The following is an example of a persistent device special file name:
where disk indicates block disk access and disk3 indicates device class disk and instance number 3. The absence of p# indicates access to the entire disk; see disk(7) for details.
The following is an example of a legacy disk device special file name:
where dsk indicates block disk access and c0t6d0 indicates logical disk access at interface card instance 0, target address 6, and unit 0. The s2 indicates access to section 2 of the disk.
The following is an example of a persistent tape device special file name:
where rtape indicates raw magnetic tape, tape4 indicates tape device instance number 4, and QIC150 identifies the tape format as QIC150; see mt(7) for details.
The support of legacy device special files is deprecated and will be removed in a future release of HP-UX.
insf(1M), ioscan(1M), lssf(1M), mksf(1M), mknod(1M), hier(5), introduction(9).
System Administration's Guide at http://docs.hp.com.
The Next Generation Mass Storage Stack whitepaper at: http://docs.hp.com/en/netsys.html#Storage%20Area%20Management.