Mass Storage Stack

The Next Generation Mass Storage Stack manages I/O devices, such as SCSI logical units (LUNs). In this release, the mass storage stack delivers functionality designed to enhance server scalability, adaptability, and performance while retaining backward compatibility. New features include:

agile addressing
native multi-pathing
increased parallelization

Overview

Release HP-UX 11iv3 introduces a new view of mass storage, called the agile view. This view includes:

new persistent disk and tape device special files
a new naming convention
minor number format that supports much larger I/O configurations.

The agile view also represents hardware pathing to disk and tape devices in ways that support larger configurations and transparent multi-pathing.

By default, most commands show a legacy view of mass storage compatible with prior releases. Users select the agile view with command line options or GUI toggles, as documented for each command.

Several new terms have been introduced to describe hardware pathing and device special files.

Hardware pathing:

In this release, there are three different types of paths to a device.

legacy hardware path
lunpath hardware path
LUN hardware path

All three are numeric strings of hardware components, with each number typically representing the location of a hardware component on the path to the device.

The legacy hardware path is 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. An example of a legacy hardware path is 0/0/2/0.1.7.0. This is the format printed in the legacy view and what has been presented in previous releases.

The lunpath hardware path is for mass storage devices, or LUNs. It is identical in format to a legacy hardware path up to the HBA. Elements beneath the HBA are in hexadecimal. The leading element(s) represent a transport-dependent target address. The final element is a LUN address, a 64-bit representation of the LUN identifier reported by the target. This format is printed in the agile view. The strings 0/2/1/0.0x50001fe1500170ac.0x4017000000000000 and 0/1/1/0.0xd.0x0 are examples of lunpath hardware paths.

The LUN hardware path is a virtualized path that represents all the lunpaths to a single LUN. It is printed in the agile view. 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. 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. Reinstalling a system or installing an identically configured system may create a different set of LUN hardware paths.

Device Special Files:

Similar to hardware paths, there are two types of device special files for mass storage:

legacy device special files
persistent device special files

Both can be used to access a given mass storage device independently and can coexist on the same system.

A legacy device special file is associated with the legacy view. It 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. It was the only type of mass storage device special file in prior releases.

Because of its naming convention and minor number format, the legacy device special file supports a maximum of 256 external buses and a maximum of 32768 LUNs. Systems with mass storage devices beyond those limits cannot address them using legacy device special files.

A persistent device special file is associated with a LUN hardware path and is seen in the agile view. Because it is based on the LUN hardware path, it transparently supports agile addressing and multipathing. 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 persistent device special file's minor number contains no hardware path information, and its name follows a simplified naming convention:

/dev/[subdir]/[class][instance]

where:

[ subdir] is the subdirectory for the device class, such as disk, tape, rdisk, or rtape
[class] is the device class, either disk or tape
[instance] is the instance number assigned 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.

Summary of Change

What’s New for Customers Migrating from HP-UX 11i v1 September 2005?

See “What’s New for Customers Migrating from HP-UX 11i v2 June 2006?”

What’s New for Customers Migrating from HP-UX 11i v2 June 2006?

The next generation mass storage stack enables the following features:

Scalability:

Unlimited number of I/O busses, up from 256
16384 LUNs supported per system, up from 8192 active LUNs
LUN size over 2TB
32 distinct I/O paths to a LUN, up from 8

Agile Addressing (sometimes referred to as Persistent LUN Binding):

New persistent device special files that track a SCSI LUN regardless of hardware path changes or multi-pathing
New naming convention for mass storage devices such as (/dev/disk/disk#, /dev/tape/tape#)
New virtualized hardware paths for multi-pathing

Multi-Pathing

Built-in multi-pathing with transparent load balancing, with a choice of load balancing algorithms
Automatic detection and recovery of path failures

Adaptability

Automatic detection of new SCSI LUNs or changes to SCSI LUNs
Automatic creation of new device special files for new LUNs
Asynchronous notification of changes to management software such as volume managers or file systems
Health tracking of all mass storage devices

Impact

Most commands that deal with I/O or mass storage have been updated to understand the agile view. They allow both persistent and legacy device special files and legacy, lunpath, and LUN hardware paths. As a rule, commands function in the legacy view unless the agile view is explicitly requested.

Some commands have more extensive changes than just support of the new mass storage stack and some commands may only function in the agile view. Such changes are covered in the section of this document that relates to the particular command (for example, LVM).

Updated commands and manpages include but are not limited to the following:

intro(7), scsimgr(1m), scsictl(1m), diskinfo(1m), setboot(1m), crashconf(1m), fcmsutil(1m), scsimgr_esdisk(7), scsimgr_estape(7), scsimgr_eschgr(7), scsi(7), disk(7), scsi_ctl(7), scsi_disk(7), scsi_tape(7), ioscan(1m), insf(1m), mksf(1m), rmsf(1m), lssf(1m), ioinit(1m), io_redirect_dsf(1m), ioconfig(4), iofind(1m), sar(1m), pstat(2), mknod(1m), mt(7) , and autochanger(7)

Compatibility

The next generation mass storage stack is intended to supersede the existing mass storage stack. However, both stacks exist in parallel. Existing legacy device special files work as before; they are completely backward compatible and are not affected by any persistent device special files on the same server. All commands are backward compatible as well and function with either legacy or persistent device special files.

One compatibility issue deals with multi-pathed devices accessed through legacy device special files. By default, multi-pathing is enabled along any hardware path to a LUN. In particular, even if legacy device special files are used for I/O, requests may still be routed through a different hardware path. This is done to maximize availability and parallelism. To force legacy device special files to use backward-compatible multi-pathing behavior, use the scsimgr command to configure a global device tunable called leg_mpath_enable.

Performance

Features of the mass storage stack improve system performance in several ways:

Native multi-pathing and load balancing increases I/O bandwidth
Dramatic reduction of I/O scan times, both at boot time and in response to an ioscan: parallelized I/O reduces scan time to between 1/4 and 1/10 time
Increased level of concurrent I/O operation
Increased Max I/O size from 1MB to 2MB

Documentation

For an overview of the Next Generation Mass Storage Stack, please see the white paper entitled The Next Generation Mass Storage Stack available at http://docs.hp.com/en/netsys.html#Storage%20Area%20Management.

For details on new or modified commands, please check their associated manpages or section(s) of this document.

Obsolescence

As of this release, the legacy view is deprecated. Use of legacy device special files and legacy hardware pathing will be obsoleted in a future release.