Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
HP-UX System Administrator's Guide: Overview: HP-UX 11i Version 3 > Chapter 3 Major Components of HP-UX

Storage on HP-UX


Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Glossary

 » Index

Of all the resources managed by any operating system, arguably the most important is storage. Storage is a generic term referring to devices that store data. Storage can take many forms, including:

  • Physical disk drives locally attached to a server:

    • SCSI hardware protocol disks

    • Fibre Channel disks

    • USB 2.0 disks

  • Drive enclosures containing multiple physical disks locally attached to a server

  • Disk arrays (drive enclosures as with the previous item but with a disk controller added to the enclosure to manage disks within the enclosure) attached locally to a server (sometimes called JBODs—for Just a Bunch Of Disks—and sometimes called RAIDs—for Redundant Arrays of Inexpensive Disks)

  • Storage Area Networks (SANs), physical disks or disk arrays as above, but configured and accessed through a special high speed network. SAN storage can be physically near the servers accessing it or physically distant for disaster protection. Storage Area Networks work at the block I/O layer, below the file system layer.

  • Network Attached Storage (NAS), an alternate network storage solution, working at the file system layer using standard network protocols (NFS, CIFS)

  • Off line storage or removable media. Data are stored on:

    • Tapes (DLT, DDS, Reel, and other tape formats)

    • Optical Media (CD, Magneto-optical, DVD-ROM, and other optical formats)

    • Removable disk drives

    Offline storage is often used for off site storage of data (usually backups) for purposes of disaster recovery.

Storage Uses

In the HP-UX operating system, storage can be used in many ways; among them:

  • Files and Directories stored locally in file systems

  • Databases stored on disk volumes in raw form (managed by the database application rather than by HP-UX) for speed

  • Swap space (used by HP-UX for paging purposes)

  • Dump space (used to capture the state of HP-UX following a system panic or other significant event)

How Storage is Organized

Like networking and many other subsystems in the computing world, storage is comprised of many layers, from the physical devices to the applications that read and write data to those devices. Collectively these layers are known as the storage stack.

The following sections cover the various components of the HP-UX storage stack.

Physical Storage Devices

At the lowest level of the storage stack are the physical devices that store and retrieve data. Usually these are disk drives, but they can be other storage devices as well, including:

  • DLT tape drives / libraries

  • Magneto-optical drives / libraries

  • DDS tapes

Disk drives can be:

  • Individual drives

  • Drive enclosures (groups of multiple disk drives that are treated as individual drives)

  • Disk Arrays (like drive enclosures but with an added disk controller for local intelligence in managing the contained storage (for example, RAIDs)

  • SAN - Storage Area Networks (physical drives attached to a dedicated network)

  • NAS - Network Attached Storage (storage attached to dedicated servers accessed through standard network file system protocols)

Individual disk drives (whether standalone or in an array or enclosure) are often referred to as LUNs. The term “LUN” stands for “Logical Unit”, and while it is often associated with a physical disk drive (drive unit) within a larger array device, LUNs can point to other (logically defined) subsets of a larger device.

Volume Managers

Physical disk drives can be used in a standalone mode; that is, they can be partitioned, formatted with a file system, used for paging, or used by database applications as units of storage. However, physical disk drives are usually grouped into larger pools of space that can then be divided into logical storage containers. These containers (called volumes or logical volumes, depending on which volume manager you are using) are not required to respect the boundaries of the physical drives in the group. That is, they can span multiple physical devices.

Volume managers enable you to divide and allocate these pools of space into logical storage containers.

The pools of space are called volume groups in the Logical Volume Manager (LVM) and disk groups in the VERITAS Volume Manager (VxVM).

The logical storage containers are referred to as logical volumes in LVM or simply volumes in VxVM. To applications, file systems, and databases, these volumes appear to be physical disks and are treated as such.

HP-UX 11i version 3 supports the following volume managers:


The Logical Volume Manager (LVM) is detailed in HP-UX System Administrator’s Guide: Logical Volume Management. LVM is the default volume manager for HP-UX 11i.


The VERITAS Volume Manager (VxVM) has many features, some of which are not available with LVM or MirrorDisk/UX (the companion product to LVM that allows you to mirror data onto multiple physical disks).

The version of VxVM that ships with HP-UX is a base version containing a subset of the features offered in the full version (which requires an additional license). For complete information about which features are included with the base version and the full version of VxVM see the VERITAS Volume Manager Releases Notes corresponding to the version of the VERITAS Volume Manager you are using.

NOTE: The pools of space are called volume groups in the Logical Volume Manager and disk groups in the VERITAS Volume Manager.

Both volume managers can co-exist on a server. Each volume manager keeps track of which disks it is controlling and any given physical disk can only be a controlled by one volume manager at a time. The utility vxvmconvert can convert an LVM physical volume to a VxVM disk if you want to migrate a disk from LVM to VxVM for greater configuration flexibility.

Selecting a Volume Manager

With HP-UX 11i version 3, there are two volume managers to choose from:

  • The HP Logical Volume Manager (LVM)

  • The VERITAS Volume Manager (VxVM)

You can use both simultaneously (on different physical disks), but usually you will choose one or the other and use it exclusively. Table 3-1 provides a comparison of the two volume managers to help you determine which will best suit your needs.

Table 3-1 Volume Manager Feature and Terminology Comparison

FeatureHP Logical Volume Manager (LVM)VERITAS Volume Manager (VxVM)


LVM is included in the HP-UX 11i version 3 Foundation Operating Environment

Check HP-UX 11i version 3 Release Notes to see if VERITAS Volume Manager is included with your chosen Operating Environment

Physical Disks are called...Physical VolumesVERITAS Volume Manager Disks

Groups of Physical Disks are called...

Volume GroupsDisk Groups

Logical Storage Containers allocated from the Volume/Disk Groups are called...

Logical Volumes


User data within (Logical) Volumes is allocated using...

Physical Extents (fixed size chunks of disk space, the size of which must be the same for all physical volumes in a given volume group)

Subdisks (arbitrary in size, subdisks represent a set of disk blocks, allocated from VERITAS Volume Manager Disks in a disk group)

Volume and Volume Group configuration information is stored in...

a special reserved area at the beginning of each physical volume.

a special area known as a “private region” of each physical volume.

Mirrors (copies of data)

You need to add the MirrorDisk/UX product to your system to support mirroring. Mirrordisk/UX supports up to three copies of data if you are using LVM with Version 1 volume groups, and up to six copies of data if you are using LVM with Version 2 volume groups.

Mirrors consist of plexes, each of which is a copy of the volume being mirrored. The base version of the VERITAS Volume Manager allows you to mirror your root file system (only).

Like LVM, VERITAS Volume Manager requires an additional license to support mirroring (beyond the mirroring of your root file system), but with the additional license VxVM supports up to 32 copies of your data.


NOTE: VERITAS Volume Manager is available in several versions as of the Release of HP-UX 11i version 3. Values and features shown are for VxVM Version 4.1. Consult the VERITAS Volume Manager Release Notes of the appropriate version for that version’s specifications.

The VERITAS Volume Manager has two licensing levels, base and full. Unless stated otherwise, the features listed in the previous table are for the base level license. See the VERITAS Volume Manager documentation for the additional features supported with the full license level.

Volume Groups

When using a volume manager, the first step is to group physical drives into pools of disk space called:

  • disk groups, if you are using the VERITAS Volume Manager (VxVM)


NOTE: The individual disks in the disk/volume groups are called:
  • VM disks, if you are using the VERITAS Volume Manager (VxVM).


  • physical volumes, if you are using the Logical Volume Manager (LVM)

(Logical) Volumes

Once you have grouped physical disk drives into disk/volume groups, the collective space can be divided into logical storage containers that can be smaller or larger than any individual drive in the group. These logical storage containers are called:

  • volumes, if you are using the VERITAS Volume Manager (VxVM)


Once defined, individual volumes or logical volumes can be used for:

  • booting (they can contain bootstrap loaders, offline diagnostics, and other software needed for server administration purposes)

  • file systems (traditional file storage)

  • swap space (virtual memory / paging)

  • dump space (memory dumps following a system panic)

  • raw disk access (for use by database applications, and other applications that manage their own disk space)

Logical volumes can be made larger or smaller as needed (if the data they contain support these operations).

Figure 3-2 Logical Volumes can be Resized

Logical Volumes can be Resized

File Systems

If you are not using a volume (or physical disk) for swap space or raw disk access (for example disk space managed by a database application), you are probably using it for file storage.

The directories, files, and file data are usually distributed throughout a volume or disk drive. In the same way a card catalog allows you to locate a specific book in a large library, the primary function of a file system is to maintain the pointers to the files stored in a volume or on a physical disk so that those files can be later retrieved. These are not merely pointers indicating which file is in which directory; these are the low level pointers and other vital information, for example:

  • which disk blocks belong to which file

  • which disk blocks are currently unused (so that specific disk blocks are not simultaneously used for more than one purpose and order is maintained)

  • linked lists of directory navigation information

File systems also have other important functions, for example maintaining ownership and access privilege information so that HP-UX security functions can ensure that only those authorized to access a file or directory can do so.

Supported File Systems

As with volume managers, HP-UX offers you several choices of file system types to choose from. Specifically:


The HP proprietary High-Performance File System supports files and file system sizes up to 128GB.


The VERITAS File System Version 4.1 supports file sizes up to 16TB and file system sizes up to 40TB. VxFS is also known as OnlineJFS/JFS 4.1.

In addition to the previous file system types, HP-UX 11i version 3 supports:


The CD file system allows you to read and write compact disc media using ISSO-9660 format (either with or without the Rockridge Extensions).


The UDF file system is used for reading optical media written in the UDF format. This allows you to read discs written by other operating systems that support the UDF format.


The 32-bit File Allocation Table file system is used primarily for boot and EFI operations.

Efficient Data Access

If your operations depend on high performance disk I/O, in addition to ensuring that you are using high-speed interfaces (for example, Fibre Channel), consider the following:

Disk Striping

Disk striping spreads data over multiple physical devices in such a way that successive writes occur on different devices. In this way, the second chunk of data to be written does not have to wait for the device writing the first chunk to finish. In essence, if you have n devices striped together, then you can write n chunks of data simultaneously (or nearly simultaneously) without having to wait for devices to become ready for subsequent data.

Striping can be performed at the device level if you are using a disk array, RAID array, or other hardware that supports RAID operations. Other types of disks striping can be performed by LVM or the VERITAS Volume Manager (VxVM). For information about performing striping using one of the volume managers, see lvcreate(1M) or vxassist(1M).

You can specify the size of data chunks to use with striping.

Hardware data striping is accomplished by using certain RAID configurations. Striping related RAID levels commonly used on HP disk arrays that support RAID are:


Striping using data blocks with no parity disks in the stripe. For performance reasons, data blocks are usually a multiple of 512 bytes (the physical sector size of most hard disks).

An important consideration when using RAID 0 is the number of disks in the stripe. The more disks you have in the stripe, the greater the chance of one of them failing. With no parity disk included in the stripe, missing data cannot be reconstructed and therefore must be restored from a backup or other source.


Striping using data blocks with parity information evenly distributed across the devices in the stripe set. The parity information can be used to reconstruct the missing data if a drive should fail.

The stripe set can function with one missing drive and, when the failed drive is replaced, the parity information on the remaining drives can be used to reconstruct the missing data (formerly on the failed drive). Once reconstruction is complete, the new disk drive fully participates in the set to help protect against data loss should a different drive fail later on.

NOTE: Not every device supports every RAID level. Check the hardware documentation for your disk arrays, RAID arrays, disk drives, or other storage equipment for information about which RAID levels are supported by your devices.

Distributing Disk Access

For the same reasons as described in Disk Striping, the more you can balance disk access, the better performance you will achieve from disk reads and writes. This reduces the chance that a given device will be busy servicing another data access operation, causing additional reads and writes to wait.

File System Type

Your choice of file system type can also affect the efficiency of accessing your data. The VERITAS File System (VxFS) is generally faster than using the HFS file system.

Establishing Multiple Paths to a Device (for efficiency)

Beginning with HP-UX 11i version 3, HP-UX 11i supports device multipathing, a new technology that associates device files with devices by using unique device IDs rather than the hardware path to the devices. This means that a single device file can represent multiple hardware paths to a given device which, when combined with hardware that has multiple ports (supporting multiple physical connections), yields not only redundant paths to the device, but greater I/O bandwidth. HP-UX 11i version 3 can automatically load balance between multiple physical connections to a device, improving I/O efficiency.

For more information on device multipathing, see “How Storage is Addressed”.

Disk Mirroring (for performance)

Though the topic of disk mirroring is more of a data redundancy topic, there are performance reasons for mirroring. If you use a RAID 1 (mirroring) disk configuration in an environment more focused on reading data from the disks rather than writing data to the disks in the mirror, you can significantly speed up data input because subsequent disk blocks can be retrieved in parallel from alternating devices. For additional benefits of using RAID 1 configurations, see “Disk Mirroring”.

Storage and Data Redundancy

The value of most data in the information age ranges from important to critical. The importance of data redundancy is directly proportional to the importance of the data being protected.

Data redundancy can take many forms but in every form multiple copies of your data exist so that if the primary copy of the data is damaged or destroyed another copy of those data can be used to continue your operations.

When choosing a data redundancy technology consider the following:

  • How quickly do you need to recover from data loss?

  • How easy is it to switch over to the alternate copy of your data should the primary become unusable?

  • Do you need off site copies of your data?

  • How often do the data change?

Establishing Multiple Paths to a Device (for redundancy)

One of the key points to protecting your data is eliminating single points of failure. RAIDs and other Disk Arrays, Disk Mirroring, and Data Backups, and Serviceguard are all about eliminating single points of failure.

Beginning with HP-UX 11i version 3, HP-UX 11i supports device multipathing, a technology that associates device files with devices by using unique device IDs rather than the hardware path to the devices. This means that a single device file can represent multiple hardware paths to a given device which, when combined with hardware that has multiple ports (supporting multiple physical connections), yields not only greater I/O bandwidth but also redundant paths to the device. HP-UX 11i can now automatically failover to an alternate hardware path should an interface card, cable, or other piece of hardware fail, and it can do this with little or no interruption to applications and users accessing the device.

RAIDs and other Disk Arrays

Disk arrays, and collections of independent disks configured using RAID configurations are capable of mirroring data from one physical disk to one or more additional physical disks, thereby giving you additional copies of the data should one drive mechanism fail. Simply having a second copy of the data exponentially decreases the chance of a failure of all copies of your data.

Hardware data mirroring is accomplished by using certain RAID configurations. Mirroring related RAID levels commonly used on HP disk arrays that support RAID are:


Mirroring data to one or more additional disks provides redundancy and the ability to take a copy of your data offline for example to snapshot the current state of the disk to a backup set for offline/off site storage.

NOTE: Not every device supports every RAID level. Check the hardware documentation for your disk arrays, RAID arrays, disk drives, or other storage equipment for information about which RAID levels are supported by your devices.

Disk Mirroring

The previous section discussed disk arrays and RAID configurations primarily from a hardware perspective. Disk mirroring can also be accomplished in software. The volume managers LVM and VERITAS Volume Manager can be used to mirror data.

In order to implement disk mirroring using LVM, you need to install the MirrorDisk/UX product (which is available as an optional product in the following Operating Environments):

  • HP-UX 11i v3 BOE

  • HP-UX 11i v3 VS-OE

  • HP-UX 11i v3 HA-OE

  • HP-UX 11i v3 DC-OE

Mirrordisk/UX supports up to three copies of data if you are using LVM with Version 1 volume groups, and up to six copies of data if you are using LVM with Version 2 volume groups.

Using the base version of VERITAS Volume Manager you can mirror only your root file system. By purchasing and installing the full version of VERITAS Volume Manager, you can mirror other disk groups and have up to 32 mirror copies of a volume’s address space.

Data Backups

At any point in time, data can be copied using any one of a number of utilities. The destination for the copies of data can be removable media that can be stored off site or shipped to another location for safe keeping. Removable media that can be used for backups include:

  • other disks

  • magnetic tapes

    • DLT

    • DDS

  • optical discs

    • recordable DVDs

    • recordable CDs

    • magneto-optical disk libraries

You can even back up files to a file on an alternate disk (as in the case of a tar archive).

Backup Utilities

There are many utilities in HP-UX to backup your data:

  • pax

    The pax command extracts, writes, and lists archive files and copies files and directory hierarchies. A more contemporary utility, pax performs basically the same functions as the older (still available) utilities cpio and tar. For details about pax, see pax(1).

  • shar

    The shar command bundles the named files and directories into a single distribution package suitable for mailing or moving. The files can contain any data, including executables. The resulting package, written to standard output, is a shell script file that can be edited (for example, to add messages at the beginning).

  • vxdump

    vxdump copies to magnetic tape all files in a VxFS file system that have been changed after a certain date. See vxdump(1M).

  • fbackup (recover data using frecover), an HP-UX specific backup utility for backing data up to the previous media types.

  • tar

    tar (called the “tape archiver”) can write to disk archive files or optical media. tar is compatible with many other operating systems, including other versions of UNIX, Linux, and Microsoft Windows.

  • cpio

    The cpio command saves and restores archives of files on magnetic tape, other devices, or a regular file, and copies files from one directory to another while replicating the directory tree structure. When cpio completes processing the files, it reports the number of blocks written.

In addition to backing up to removable media, you can copy important files to another system using ftp, rcp, or (for secure copies) sftp.

How Storage is Addressed

The various components that comprise the HP-UX storage stack are addressed in different ways:

Table 3-2 Storage Components and how they are Addressed

Stack ComponentHow it is addressed

File System

Once created, a file system is usually addressed by its mount point, the directory in the HP-UX directory tree that represents the root of the files in that file system.

RAW access

Not all logical / physical volumes contain file systems. Other uses of these volumes include:

  • swap space

  • dump space

  • database managed space

Swap and dump space are managed by the kernel, and database managed space is usually managed by the database application.

(Logical) Volumes

The logical containers allocated from space in a volume group or disk group are addressed by their volume name. Because these volumes are disk drives from the perspective of the operating system, they have associated device files.

LVM logical volumes have device files with names of the form:

  • /dev/vgxx/lvoln

  • /dev/vgxx/rlvoln

where xx represents the volume group that the logical volume belongs to, and n represents the logical volume number within that volume group. The directory lvoln contains the block device special files and the directory rlvoln contains the character device special files.

VxVM volumes have device files with names of the form:

  • /dev/vx/dsk/diskgroupname/volnn

  • /dev/vx/rdsk/diskgroupname/volnn

where diskgroupname is the name assigned to the volume group associated with the device files and nn represents the volume number.

Volume / Disk Groups

LVM Volume Groups have names, usually of the form “vgnn” (where nn represents the volume group number). The volume group that contains the root file system (if the root file system is contained in an LVM logical volume) is vg00.

If you are using the VERITAS Volume Manager (and your root file system is contained in a VxVM volume), the root VxVM disk group is usually called rootdg[1].

Physical Disks

The fundamental building blocks of both LVM Volume Groups and VxVM Disk Groups are physical disk drives.

[1] In releases of VERITAS Volume Manager (VxVM) prior to release 4.0, a system installed with VxVM was configured with a default disk group, rootdg, that had to contain at least one disk. By default, operations were directed to the rootdg disk group. Beginning with VxVM release 4.0, VxVM can function with no disk groups configured. There is no longer a requirement that you name any disk group rootdg, and any disk group that is named rootdg has no special properties because of that name.


Device Special Files

HP-UX, applications, and other processes communicate with devices and pseudo-devices by writing to and reading from device special files. Device special files are in a special format that tells HP-UX:

  • Whether to communicate with the device using character or block transmissions

  • Which device driver to use when communicating with the associated device

  • How to locate/identify the device

  • Any driver-specific attributes needed for communicating with a device

The first two items in the list above are determined by the major number of a device special file, the latter two items are determined by the minor number of a device special file.

The Anatomy of a Device Special File

Device Special Files (DSFs) are comprised of the following parts:

file name

This is the name of the file that appears in the /dev directory tree

major number

A number used to identify which driver to use to communicate with the device/LUN associated with that device special file

The major number is an index for the device driver into one of two kernel tables — bdevsw, the block device switch table and cdevsw, the character device switch table.

Drivers that support both block and character I/O (such as SCSI disk driver and optical autochanger) have both a block major number and a character major number. Devices that support only character-mode access have only a character major number.

minor number

A number that identifies the hardware location and sometimes driver-dependent characteristics (usually organized by bit assignments).

The three parts of a device file can be viewed using the ll (ls -l) command. For example:

Figure 3-3 Device Special File Components

Device Special File Components

You can view, in more human readable form, information contained in the device special file using the /usr/sbin/lssf command. For example:

# /usr/sbin/lssf /dev/rdsk/* sdisk card instance 0 SCSI target 6 SCSI LUN 0 section 0 at address 0/0/0/2/0.6.0 /dev/rdsk/c0t6d0sdisk card instance 2 SCSI target 6 SCSI LUN 0 section 0 at address 0/0/0/3/0.6.0 /dev/rdsk/c2t6d0 # /usr/sbin/lssf /dev/disk/* esdisk section 0 at address 64000/0xfa00/0x0 /dev/disk/disk2 esdisk section 0 at address 64000/0xfa00/0x1 /dev/disk/disk3

The /usr/sbin/ioscan command will also show you hardware path information about the devices on your system:

Here is the legacy view of the disk drives on a system:

# /usr/sbin/ioscan -C disk H/W Path Class Description ===================================================== 0/0/0/2/0.6.0 disk HP 36.4GMAN3367MC 0/0/0/3/0.6.0 disk HP 36.4GMAN3367MC

Here is the agile view of the same disk drives (showing the virtual LUN hardware paths rather than the actual hardware paths):

# /usr/sbin/ioscan -N -C disk H/W Path Class Description ===================================================== 64000/0xfa00/0x2 disk HP 36.4GMAN3367MC 64000/0xfa00/0x3 disk HP 36.4GMAN3367MC
Legacy versus Agile Device Addressing

Beginning with HP-UX 11i version 3, mass storage devices are referenced by device instances rather than by the hardware paths to the devices. This has many benefits over the previous addressing scheme which associated a given device special file with the hardware path to a device. Device hardware addressing for mass storage devices is now fluid, automatic, and transparent. This has many benefits.

NOTE: For compatibility with previous HP-UX releases, the previous (legacy) device addressing scheme for mass storage devices is still supported under HP-UX 11i version 3; therefore scripts, configurations, and other uses of device special files you have previously created will continue to work.

For transition purposes, you can use both legacy device addressing (using legacy device special files) and agile device addressing (using persistent device special files) simultaneously, but to take advantage of the many benefits of agile device addressing, and for future compatibility reasons, you should transition to using persistent device special files going forward once all of the underlying file systems and technologies that you use can support them.

Greater Configuration Stability

Agile device addressing allows for hardware paths to change between system boots (for example, if a LUN is moved from one HBA to another while a server is shutdown) and for SAN configurations to change without requiring changes to device special files (and therefore without requiring changes to other configuration files). If you replace a disk associated with a persistent device special file (the type of device special files that provide agile device addressing), you can use the io_redirect_dsf command to update the persistent device special file to reference the replacement disk. For details, see the manpage io_redirect_dsf(1M).


Because of a limitation in device special file minor numbers, a server was previously limited to 256 bus instances. Using agile device addressing you can now address more than 256 bus instances.

Agile device addressing also allows you to address a greater number of LUNs. HP-UX 11i version 3 supports up to 16,384 LUNs.


Each LUN can have up to 32 physical I/O paths. HP-UX 11i version 3 automatically discovers and configures new physical I/O paths to a LUN and balances data flowing through the various paths to a given device using one of the following load-balancing policies:


This load balancing policy selects a LUN based on its affinity with the processor core issuing the I/O, minimizing latency.


This load balancing policy is applicable to HP cell-based platforms. The LUN paths are selected in a round robin manner within the locality of CPU on which the I/O was initiated, to ensure that memory access latencies are optimized.


Directs I/O requests through the hardware path with the least outstanding I/O requests.


Cycles I/O requests through available hardware paths in round robin fashion.


Directs I/O requests through a single hardware path; specifically, the path with the fewest outstanding I/O requests when the device is opened. This is the default load balancing algorithm for serial devices (for example tape drives).


The I/O path set in the preferred_path attribute is preferably used for I/O transfer. If this I/O path is not available or if the preferred_path attribute was not set, any other path is selected for I/O transfer. This policy is useful for certain disk arrays, which may exhibit some performance degradation if I/Os are transferred via several I/O paths to a LUN simultaneously.


This load balancing policy selects LUN paths from a preferred list unless none are available (or defined), in which case other LUN paths are selected.


This load balancing policy selects an I/O path based on a weighted round robin algorithm

Use the scsimgr command to specify which of the previous policies should be used for a given device.

NOTE: Not every device supports every load balancing policy. The type of device determines which of the previous policies you can use. For details see the following manpages:

HP-UX can also automatically re-balance the loads on remaining data paths to a LUN should one or more of those paths fail.

NOTE: Use the scsimgr command (see scsimgr(1M) for details) to set the load balancing algorithm. An algorithm choice can be set individually for each LUN, or for all LUNs on the server. Also, the choice can be permanently set (value retained across reboots), or temporarily set (until the next reboot).
Device Special File Directories (and Name Formats)

Device Special Files are located in the /dev directory and many are organized in a series of sub-directories within /dev. Two of these directories contain the persistent device special files defining the physical disk drives on a server:


Contains persistent device special files for block mode access to physical disk devices on a server.


Contains persistent device special files for character mode access to physical disk devices on a server.

Within the previous directories, files have names in the format “diskN” (where “N” is the instance number of the disk).


/dev/disk/disk15 /dev/rdisk/disk7

An optional part of a device file name for a disk can be appended to represent disk partition numbers. By convention, in the absence of this optional part of the device file name the name represents an entire disk. This optional part expands the format of the name to be diskN_p# (where p# represents the partition number, tape density, or other information).


/dev/disk/disk15_p3 /dev/rdisk/disk7_p1

The following directories still exist in HP-UX 11i version 3 for backwards compatibility. They contain the legacy device special files defining the physical drives on a server (the legacy form):


Contains legacy device special files for block mode access to physical disk devices on a server.


Contains legacy device special files for character mode access to physical disk devices on a server.

Within these directories, files have names in the format “c#t#d#” (where c# represents the controller instance number, t# represents the SCSI target number, and d# represents the SCSI LUN number).


/dev/dsk/c3t7d0 /dev/rdsk/c3t15d5

With legacy device special files that are associated with disks an optional part of the filename can represent disk partition numbers. By convention, in the absence of this optional part of the device file name the name represents an entire disk. This optional part expands the format of the name to be c#t#d#s# (where s# represents the partition number, tape density, or other information).


/dev/dsk/c3t7d0s3 /dev/rdsk/c3t15d7s1
NOTE: You can use both legacy and persistent device special files simultaneously but to gain the many benefits of persistent device special files, you need to use those.

For example, using legacy device special files you can only define and address up to 256 external buses on a server. If you have more than 256 you will need to use persistent device special files to access the devices beyond the 256 address boundary.

For Additional Information on Naming Device Special Files

Additional information on naming device special files is located in the following manpages:

Mass Storage Hardware Paths (three formats)

Hardware paths, as the name implies, define the physical paths that data travels to reach devices. In HP-UX 11i version 3 there are three formats to specific hardware paths to mass storage devices.

Legacy Hardware Paths

This is the format used in releases prior to HP-UX 11i Version 3. It is composed of a series of bus-nexus addresses separated by slash characters (“/”) leading to the host bus adapter (HBA); beneath the HBA, additional address elements are separated by periods (“.”).

For directly connected devices, the addressing can be a simple target and LUN:


For SCSI-3 devices connected through a storage area network (SAN), legacy addressing is emulated with a domain, area, port, virtual bus, virtual target, and virtual LUN:


Lunpath Hardware Paths

This format is used for addressing LUNs in agile mode. It is identical to the legacy hardware path format up to the host bus adapter (HBA). Beneath the HBA, two additional address elements are represented (in hexadecimal):

Target address

A transport dependent address identifying the physical device associated with the hardware path

LUN address

A 64-bit representation of the LUN identifier reported by the target.

0/2/1/0.0x50001fe1500170ac.0x4017000000000000 is an example of a SCSI-3 hardware path.

Figure 3-4 Lunpath Hardware Path Components

Lunpath Hardware Path Components
LUN Hardware Paths

Because devices can have multiple physical hardware paths, a virtualized LUN hardware path is needed so that the hardware path that a persistent device special file maps to remains the same even when the underlying physical hardware path elements change.

Instead of a series of bus-nexus addresses (corresponding to specific hardware paths) leading to the HBA, virtual hardware paths use 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 ID, delimited by slash characters (“/”).

64000/0xfa00/0x22 is an example of a virtual hardware address.

Figure 3-5 LUN Hardware Path Components

LUN Hardware Path Components

Example 3-2 Hardware Path Format Summary

The three formats described previous are different ways of referring to the same LUN, so a single LUN could have all of the following addresses:

0/2/1/ 0/2/1/ 0/4/1/ 0/4/1/ 0/2/1/0.0x50001fe1500170ac.0x4017000000000000 0/2/1/0.0x50001fe1500170ad.0x4017000000000000 0/4/1/0.0x50001fe1500170ac.0x4017000000000000 0/4/1/0.0x50001fe1500170ad.0x4017000000000000 64000/0xfa00/0x22

In the previous example the LUN has four physical hardware paths. The first four lines represent them using the legacy hardware path format, the next four lines represent them using the SCSI-3 hardware path format, and the final line represents the single virtual hardware path (used for all four physical paths).

HP-UX 11i version 3 commands will accept any of these three formats to specify a hardware path to a LUN.

Commands Associated with Device Special Files

Here is a list of key commands used for managing device special files:


Used during boot to create both legacy and persistent device special files for new devices. insf can also be used manually, while the system is running, to create such device special files (for example, if ioscan caused new hardware to be discovered insf could be run to create device special files for that new hardware without having to wait for a reboot of the system)[3]. See insf(1M) for details.

With the -L option, insf enables the legacy naming model.


Used to create a single device special file, usually with non-default characteristics. For details on specifying the parameters for your device special file, see mksf(1M).

If you wish to create a single device special file, perhaps with specific parameters, use mksf instead of insf. For details on specifying the parameters for your device special file, see mksf(1M).


lssf lists information about specified device special files (in a friendly, human readable form). For example, lssf can list stale device special files. You can specify legacy or persistent device special files. For details and examples of lssf output, see lssf(1M).


rmsf removes specified device special files. For information about the many rmsf options for specifying which device special files to remove (and from where to remove them), see the rmsf(1M) manpage.

With the -L option, rmsf disables the legacy naming model, removing all legacy I/O nodes and their device special files from the system.


io_redirect_dsf reassigns an existing device special file from one device to another. Because this takes advantage of one of the primary benefits of persistent device special files, it will not work with legacy device special files. See io_redirect_dsf(1M) for details.


ioscan performs many functions. Primarily it scans a server’s hardware, binding new hardware with appropriate drivers. With regard to device special files, ioscan can display the mapping between legacy device special files and persistent device special files. See ioscan(1M) for details on ioscan’s many functions and options.


scsimgr, like ioscan, has many functions other than working with device special files. But, you can use scsimgr to validate the change of a LUN associated with a legacy device special file (replace a legacy device special file). If you have replaced a disk drive and are using legacy device special files, refer to the scsimgr(1M) manpage for assistance with remapping the device special file to the new device. The scsimgr command to do this is replace_leg_dsf.

For More Information on the Next Generation Mass Storage Stack

The following resources contain much more information on the components of the Next Generation Mass Storage Stack:

Managing HP-UX Swap Space

Swap space is where HP-UX stores unneeded pages of memory from running processes, a process called virtual memory paging (or simply paging) because the chunks of data moved in and out of physical RAM are called pages. This enables HP-UX to use much more memory than physically exists on a server.

Types of Swap Space

There are three types of swap space used for paging operations:

Device Swap

Swap space is initially allocated when you configure your disks. Device swap space occupies a logical volume or disk partition that is typically reserved expressly for paging purposes. This space may also be configured as a dump area but doing so has implications for memory dump integrity if a crash occurs. See “Using a Device for Both Paging and Dumping (System Recovery Time)”. Because, when HP-UX is running, the device is used exclusively for paging, you cannot also store files on it.

NOTE: There is one exception to the rule that a given logical volume cannot be used for both file system space and device swap. If you have unused space between the end of a file system and the end of the logical volume in which it resides (that is, the file system is smaller than the logical volume it is in), the unused space (not allocated to the file system), can be used as device swap space.

Device swap can only be used locally; it cannot be accessed remotely by clients using network disk access protocols.

Device swap is quickly accessed because HP-UX can get to the logical volume or disk partition directly to perform large writes or reads.

File System Swap

If the device swap space you have configured on your server is not enough and you have no more devices that you can dedicate for that device swap space, you can configure file system swap space.

File system swap allows for extra swap space if there is an occasional need for more than is allocated as device swap space. It is used only when device swap space is insufficient. File system swap space is configured as additional swap space to be allocated from unused space within a file system.

Because file system swap requires the system to perform a greater amount of processing it is usually slower than device swap and should not be used as a permanent replacement for a sufficient amount of device swap space. It is best for the occasional overflow of device swap space.

The file system used for swap can be either a local or a remote file system. Cluster clients can use remote file system swap for their swap needs. Swapping to a remote file system is slower than swapping to a local file system and is not encouraged if local device swap or local file system swap is available.

Pseudo Swap

Pseudo Swap is very different than device swap space or file system swap space. It is one of the technologies that allow you to more efficiently utilize the resources on your system.

Pseudo swap “space” does not really exist; HP-UX just behaves as though it has an extra amount of swap space. Pseudo swap takes advantage of the fact that not all swap space that is reserved is actually used. This allows a greater number of processes to run in memory than could be supported by configured swap devices. Pseudo swap is best used with large memory systems.

If you choose to use the pseudo swap capability (actually, it is enabled by default), an amount of pseudo swap space equal to 7/8ths of the amount of physical ram available to your server, nPartition, or virtual partition is used as pseudo swap.

Lazy Swap

Another technology that takes advantage of the fact that not all swap space that is reserved is actually used is lazy swap. The lazy swap feature causes HP-UX to not reserve swap space for a process-private page until the associated process actually modifies the page. This can significantly reduce the amount of allocated swap space.

Lazy swap is configured on a process by process basis. There are programmatic ways to enable lazy swap or a user can modify a binary executable file to enable lazy swap by using the +z option to the chatr command. See the chatr(1) manpage for details.

Primary and Secondary Swap Space

HP-UX must have at least one device swap area available when it boots. This area is known as the primary swap area.[4] Primary swap, by default, is located on the same disk as the root file system (though in a different logical volume). Use the swapon command (see swapon(1M)) to define swap space.

Other swap space may be used in addition to primary swap. This is known as secondary swap space. If you are using device swap as your secondary swap space, for better performance allocate the secondary swap space on a disk drive other than where the primary swap is located.

File system swap is always secondary swap.

Figure 3-6 Swap Space - Possible Locations for Paging

Swap Space - Possible Locations for Paging

Estimating Your Swap Space Needs

Your swap space must be large enough to hold all the processes that could be running at your system’s peak usage times.

If your system performance is good, and, in particular, if you are not getting swap errors such as “Out of Memory” or those to the effect that a process was killed due to no swap space, then your system has adequate swap space.

Unless the amount of physical memory on your system is extremely large, the minimum amount of swap space should equal the amount of physical memory on the system. In general, size your server’s swap space to be roughly two to four times the amount of physical memory that is used by HP-UX on your server, nPartition, or virtual partition.

Swap space usage increases with system load. If you are adding (or removing) a large number of users or applications, you will probably need to re-evaluate your swap space needs.

NOTE: To get a snapshot of the total amount of swap space currently being used, use the command:
# /usr/sbin/swapinfo -tam Mb Mb Mb PCT START/ Mb TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME dev 4096 0 4096 0% 0 - 1 /dev/vg00/lvol2 reserve - 257 -257 memory 1940 562 1378 29% total 6036 819 5217 14% - 0 -

This number will vary over time, depending on the current mix of applications running, but if the total percentage used is regularly high, roughly 90% or greater, then you probably need to add more swap space.

Once you know or suspect that you will have to increase (or decrease) your swap space, you should estimate your swap space requirements.

You can estimate the amount of swap space you need by adding the memory requirements of the applications you expect to run (simultaneously) on your system to the amount of physical memory you have.

Enabling Swap Space

When HP-UX is in the earliest stages of the boot sequence, the system begins by paging on only a single device so that only one disk is required at boot time.

During the processing of the startup script /sbin/init.d/swap_start, calls to swapon enable any additional paging areas, if any are defined in the file /etc/fstab.

Should you find the need for additional paging space while your system is running, you can also run the swapon command to manually enable additional space. See the swapon(1M) and fstab(4) manpages for details.

Disabling Swap Space

Sometimes, you can disable swap space. In order to be able to disable paging to swap areas:

  • your system must be running HP-UX 11i Version 3 September 2008 Update, or later

  • sufficient swap space must remain active (following the change) to continue to operate your system

Use the swapoff command to disable paging to a specific swap area. For example:

/usr/sbin/swapoff /dev/vg00/lvol2

Guidelines for Setting Up Swap Areas

There are some guidelines to consider when configuring swap space on your system. Most of these are focused on maximizing the performance of HP-UX.

Device Swap Guidelines

Use the following guidelines to configure the most commonly used type of swap space, device swap:

  • Interleave device swap areas for better performance.

    Two swap areas on different disks perform better than one swap area with the equivalent amount of space. This allows interleaved swapping which means the swap areas are written to concurrently, minimizing disk head movement, thus enhancing performance.

    When using LVM, you should set up secondary swap areas within logical volumes that are on different disks (physical volumes) using lvextend.

    If you have only one disk and need to increase swap space, try to move the primary swap area to a larger region on the disk.

    To see which devices are already being used for device swap use the command:

    swapinfo -d

  • Try to keep multiple device swap areas similar in size.

    Device swap areas should have similar sizes for best performance. When you configure swap areas of different sizes, when all space in the smaller device swap area is used only the larger swap area is available making interleaving no longer possible and slowing down paging performance.

  • The nswapdev tunable system parameter controls the maximum number of swap devices. Although the default value for nswapdev is large enough to accommodate nearly all HP-UX systems, verify that it is large enough to accommodate the number of swap areas you require.

File System Swap Guidelines

When you need more swap space and you have no devices available for additional device swap, or if you need to swap to a remote system, you can dynamically add file system swap to your system. Use the following guidelines:

  • Interleave file system swap areas for best performance.

    Two swap areas on different disks perform better than one swap area with the equivalent amount of space. Multiple devices allow for interleaved swapping which means the swap areas are written to concurrently, minimizing disk head movement, thus enhancing performance. This applies as much to file system swap space as it does to device swap space, so the same guideline applies.

    To see which devices are already being used for file system swap use the command:

    swapinfo -f

  • If possible, avoid configuring heavily used file systems. Heavily used has two meanings here:

    1. Actively used file systems (for example, the root file system, or those file systems used most frequently by your primary applications). This will slow down the performance of your server as paging activities compete with your applications and user file access.

    2. Very full file systems. Because file system swap uses unused space within file systems, if the file systems are very full there is not much unused space for paging use (and it is probably very fragmented within the file system). To gauge how full a file systems are, use the bdf command.

Guidelines for Assigning Swap Priority

When you add swap areas, you can assign a priority to each. Priorities range from 0 (the highest) to 10 (the lowest). HP-UX uses swap areas with higher priority first. And, HP-UX gives device swap priority over file system swap when each has the same priority. Here are the guidelines you should use:

  • Given multiple swap devices with identical performance, assign each an identical priority. By so doing, you will allow the system to use each of them on an interleaved basis which enhances performance.

  • Assign higher priorities to the swap areas that have faster performance and lower priorities to areas that are slower.

  • Do not give file system swap areas priority over device system swap areas. Although this is not absolutely necessary it enhances the swapinfo output.

  • Give lower use file systems priority over higher use file systems.

For More Information on Configuring and Managing Swap Space

The following manpages contain important information on configuring swap space:


The file /etc/fstab not only defines which file systems should be mounted to which mount points in the directory tree (see “The HP-UX Directory Structure”), it is also one of the key places you configure swap space.


lvlnboot prepares an LVM logical volume to be root, boot, primary swap, or a dump volume.


swapinfo prints information about device and file system paging space.


The swapon command enables devices or file systems on which paging is to take place.


The swapoff command disables active paging areas, if possible.

The following kernel tunables affect paging activities on HP-UX:


Maximum number of swap devices that can be enabled for swap.

[3] In some cases, new hardware is automatically discovered and associated persistent device special files are created, even before ioscan is run. However, if you have new hardware with no associated device special files, insf can create them for you.

[4] Primary swap is not mandatory if pseudo swap is enabled, however, it is strongly recommended.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 2008 Hewlett-Packard Development Company, L.P.