The XVM Volume Manager provides all of the basic features of logical volumes that were provided with XLV logical volumes, an older logical volume design developed at SGI. These features include the following:

In addition to the features that XLV logical volumes provide, the XVM Volume Manager provides the following significant features:

Logical volumes appear as block and character devices in subdirectories of the /dev directory.

Table 1-1 shows the directories that contain XVM logical volumes in the IRIX operating system.

If you are not running in a cluster environment, then all the logical volumes are considered to be local volumes.

The device names for XVM logical volumes in these directories are volname,subvolname where volname is the name of the XVM logical volume and subvolname is the name of the subvolume to be accessed under that volume.

Under Linux, block devices are contained in the following directory:

/dev/xvm/local/vol/volname/data/block

For further information on XVM logical volume device directories, see “XVM Device Directories and Pathnames” in Chapter 3. For information on names of objects within XVM logical volumes, see “Object Names in XVM” in Chapter 3.

Before you create XVM logical volumes on a disk, you must label the disk as an XVM disk. The XVM Volume Manager controls the partitioning of an XVM disk. Partitions are not used to define the storage available for XVM slices, as they are for XLV logical volumes; labeling a disk as an XVM disk removes the 16-piece partition limit of an IRIX filesystem.

---

Note: Before you can label a disk as an XVM disk, it must be formatted as an SGI disk. Under IRIX, if your disk has not been initialized during factory set-up, use the fx(1M) command to initialize the disk.Under Linux, use the fdisk command to format the disk as an SGI disk.

---

When you label a disk as an XVM disk, you can specify whether the disk will be an XVM option disk, an XVM system disk with combined root and  usr filesystems, or an XVM system disk with separate root and usr filesystems. An XVM disk is labeled as an option disk by default.

For information on labeling a disk as an XVM disk, see “Creating Physical Volumes” in Chapter 2, and “Assigning Disks to the XVM Volume Manager with the label Command” in Chapter 4. For specific information on labeling XVM disks as system disks, see “XVM System Disks” in Chapter 4.

Figure 1-1 shows the partition layout of an XVM option disk. In an XVM option disk, partition 10 contains the entire disk and partition 8 contains the volume header. The remainder of the disk that is not part of partition 8 is divided into slices that you specify using the XVM Volume Manager.

Figure 1-1. XVM Option Disk Partition Layout

Figure 1-2 shows the partition layout of an XVM system disk with combined root and usr filesystems. Partition 8 contains the volume header, partition 9 contains the XVM label area where the information about the XVM volume elements on a disk is stored, partition 0 contains the root partition, and partition 1 contains the swap partition. Partition 10 contains the entire disk.

Figure 1-2. Partition Layout of XVM System Disk with Combined root and usr Filesystems

Figure 1-3 shows the partition layout of an XVM system disk with separate root and usr filesystems. Partition 8 contains the volume header, partition 9 contains the XVM label area where the information about the XVM volume elements on a disk is stored, partition 0 contains the root partition, partition 1 contains the swap partition, and partition 6 contains the usr partition. Partition 10 contains the entire disk. In this illustration the XVM system disk includes space on the disk that can be used for other filesystems besides root, swap and usr.

Figure 1-3. Partition Layout of XVM System Disk with Separate root and usr Filesystems

---

Note: Under IRIX, if you attempt to use the fx(1M) command to modify the partition layout on an XVM disk, a warning message is generated. You can determine which disks are managed by XVM by executing a hinv -c disk -v command.

---

Figure 1-4 shows the partition layout of an XVM system disk with multiple root filesystems as well as a separate usr filesystem. Partition 8 contains the volume header, partition 9 contains the XVM label area where the information about the XVM volume elements on a disk is stored, partition 0 contains the first root partition, partition 1 contains the swap partition, partitions 2 and 3 contain additional root filesystems, and partition 6 contains the usr partition. Partition 10 contains the entire disk.

Figure 1-4. Partition Layout of System Disk with Multiple Root Filesystems

XVM logical volumes are composed of a hierarchy of logical storage objects: volumes are composed of subvolumes; subvolumes are composed of stripes, mirrors, concats (concatenated volume elements), and slices combined in whatever hierarchy suits your system needs; and, at the bottom of the hierarchy, each logical storage object is ultimately made up of slices, which define an area of physical storage. Each of these logical storage objects is known as a  volume element or a ve.

The concat, stripe, and mirror logical volume elements can be arranged and stacked arbitrarily. There is a limit of ten levels from the volume through the slice, inclusive.

A logical volume element beneath another volume element in the hierarchy is known as a child or piece of the higher-level volume element. Volumes are limited to 255 children, subvolumes are limited to 1 child, and mirrors are limited to 8 children. Other volume elements are limited to 65,536 children.

Figure 1-5 shows an example of a simple XVM logical volume. In this example, there is one data subvolume that consists of a single two-way stripe.

Figure 1-5. Basic XVM Striped Logical Volume

Figure 1-6 shows an XVM logical volume with three subvolumes and a mirrored stripe in the data subvolume.

Figure 1-6. XVM Logical Volume with Mirrored Stripe and Three Subvolumes

Figure 1-7 shows the example illustrated in Figure 1-6 after the insertion of a concat. In this example, additional slices were created on the unused disk space on the disks that made up the data subvolume. These slices were used to create a parallel mirrored stripe, which was combined with the existing mirrored stripe to make a concat.

Figure 1-7. XVM Logical Volume after Insertion of Concat

The following subsections describe the XVM volume elements in greater detail.

Volumes

A volume is the topmost XVM volume element. It is a collection of subvolumes, which are grouped together into a single volume name.

Each volume can be used as a single filesystem. Volume information used by the system is stored in logical volume labels in the volume header of each disk used by the volume.

You can create volumes, delete volumes, and move volumes between systems.

The subvolumes that make up a volume can be marked as data subvolumes, log subvolumes, and real-time subvolumes. These are the system-defined subvolume types, and are described in “Subvolumes”. You can also mark a subvolume as being of a user-defined type. (XVM on Linux does not support real-time subvolumes.)

You cannot have more than one subvolume of a particular system-defined subvolume type under the same volume. In other words, a volume can contain only one data subvolume, only one log subvolume, and only one real-time subvolume. This restriction does not apply to subvolumes of user-defined types.

Figure 1-8 shows an XVM volume with system-defined subvolume types.

Figure 1-8. XVM Volume with System-Defined Subvolume Types

Figure 1-9 shows an XVM volume with user-defined subvolume types, which have been defined as types 16, 17, and 18. In this example, the volume is named animation and the subvolumes are named wire-data, shading, and texturemap. For information on subvolumes, see “Subvolumes”. For information on XVM object names, see “XVM Object Specification” in Chapter 3.

Figure 1-9. XVM Volume with User-Defined Subvolume Types

Subvolumes

A subvolume is the entry point for XVM logical volume I/O. Each subvolume is a distinct address space and a distinct type. There can be only one volume element beneath a subvolume in an XVM topology.

Subvolumes can be of the following system-defined types:

Data subvolume		An XFS data subvolume is required for all XVM logical volumes acting as filesystem devices.
Log subvolume		The log subvolume contains a log of XFS filesystem transactions and is used to expedite system recovery after a crash. A log subvolume is optional for an XVM logical volume; if one is not present, the filesystem log is kept in the data subvolume.
Real-time subvolume		Real-time subvolumes are generally used for data applications such as video, where guaranteed response time is more important than data integrity. A real-time subvolume is optional for an XVM logical volume. Volume elements that are part of a real-time subvolume should not be on the same disk as volume elements used for data or log subvolumes. This separation is required for files used for guaranteed-rate I/O with hard guarantees. Note: XVM on Linux does not support real-time subvolumes.

System-defined subvolume types cannot have user-defined names.

A subvolume can also be marked as being of a user-defined type. You can specify a name for a subvolume of a user-defined type.

Subvolumes enforce separation among data types. For example, user data cannot overwrite filesystem log data. Subvolumes also enable filesystem data and user data to be configured to meet goals for performance and reliability. For example, performance can be improved by putting subvolumes on different disk drives.

Each subvolume can be organized independently. For example, you can mirror the log subvolume for fault tolerance and stripe the real-time subvolume across a large number of disks to give maximum throughput for video playback.

Figure 1-10 shows four examples of the composition of an XVM subvolume, showing that an XVM subvolume can contain only one child volume element.

Figure 1-10. XVM Subvolume Examples

Concats

A concat is an XVM volume element that combines other volume elements so that their storage is combined into one logical unit. For example, two slices can be combined into a single concat.

Figure 1-11 shows a concat that is composed of two slices.

Figure 1-11. Concat Composed of Two Slices

Figure 1-12 shows a concat that is composed of two mirrors.

Figure 1-12. Concat Composed of Two Mirrors

Stripes

A stripe is an XVM volume element that consists of two or more underlying volume elements. These elements are organized so that an amount of data called the stripe unit is written to and read in from each underlying volume element in a round-robin fashion.

Striping can be used to alternate sections of data among multiple disks. This provides a performance advantage by allowing parallel I/O activity.

Figure 1-13 shows a three-way stripe.

Figure 1-13. Three-Way Stripe

A stripe configured on top of another stripe may provide performance benefits over a single wider stripe. In Figure 1-14, two three-way stripes are created and then striped again using a larger stripe unit size. If configured correctly, disjoint sequential access (where different processes are doing sequential I/O to different parts of the address space) will end up on different halves of the top-level stripe. The advantage of this configuration is that for parallel large accesses, the two halves of the top-level stripe can operate independently, whereas with a single six-way stripe, multiple I/O operations would be outstanding to each disk, causing the need for a disk seek.

Figure 1-14. Stripe on Stripe Volume Element

Mirrors

A mirror is an XVM volume element that maintains identical data images on its underlying volume elements. This data redundancy increases system reliability. The components of a mirror do not have to be identical in size, but if they are not there will be unused space in the larger components.

---

Note: To use the mirroring feature of the XVM Volume Manager or to access a mirrored volume from a given node in a cluster, you must purchase the XFS Volume Plexing software option and obtain and install a FLEXlm license.

---

Figure 1-15 shows a mirror that is composed of two slices.

Figure 1-15. Mirror Composed of Two Slices

Figure 1-16 shows a mirror that is composed of two stripes.

Figure 1-16. Mirror Composed of Two Stripes

Figure 1-17 shows a mirror composed of a stripe and a concat.

Figure 1-17. Mirror Composed of a Stripe and a Concat

A logical volume can include slices from several physical disk drives. If the logical volume is not striped, data is written to the first component of a volume element until that component is full, then to the second component, and so on. Figure 1-18 shows the order in which data is written to a concatenated logical volume. In this figure, each wedge represents a unit of data that is written to disk. Data is written to the first component until it is filled, and then data is written to the second component until it is filled, and so forth.

Figure 1-18. Writing Data to a Non-Striped Logical Volume

If the logical volume is striped, an amount of data called the stripe unit is written to each underlying volume element in a round-robin fashion. Figure 1-19 shows the order in which data is written to a striped volume element with a three-way stripe. Each wedge represents a stripe unit of data. One stripe unit of data is written to the first component of the stripe, then one stripe unit of data is written to the second component of the stripe, then one stripe unit of data is written to the third component of the stripe. After this, the next stripe unit of data is written to the first component, and so forth.

Figure 1-19. Writing Data to a Striped Logical Volume

Under IRIX, the XVM Volume Manager is used by CXFS filesystems, which are shared among the nodes in a CXFS cluster.Because of this, an XVM physical volume has a domain, which can be cluster or local. An XVM physical volume with a cluster domain is owned by a CXFS cluster, while an XVM physical volume with a local domain is owned by a single node.

---

Note: SGI ProPack does not currently support SGI's CXFS cluster environment.

---

An XVM physical volume that has a cluster domain can be configured and modified by any node in the CXFS cluster that owns it. An XVM physical volume that has a local domain can be configured and modified only by the local node that owns it. The XVM logical volumes that are contained on XVM physical volumes with a local domain are considered to be local volumes.

For information on XVM domains, see “XVM Domains” in Chapter 2. For information on CXFS, see CXFS Version 2 Software Installation and Administration Guide.

If your XVM configuration requires that you spread I/O across controllers, you must have a complete failover.conf file configured. This is necessary to ensure that I/O is restricted to a chosen primary path. For example, if you want a striped volume to span two host bus adapters, you must configure a failover.conf file to specify a primary path.

For information on configuration of failover for storage devices, see your SGI support provider. Information on the failover.conf file can also be found on the failover(7M) man page and in the /etc/failover.conf file itself.

If you are running the “f” release leg of the IRIX operating system, you can use the XVM Volume Manager as a standalone volume manager, a separate product from CXFS.

---

Note: If you will be using the mirroring feature of XVM, you must obtain and install the XFS Volume Plexing option, which requires a FLEXlm license. Contact SGI or your local service provider for information on obtaining and installing this license.

---

To use XVM as a standalone product under IRIX, you will need to specify that the eoe.sw.xvm module is installed when you install your system. This module is not installed by default.

If you are already running the “f” release leg of IRIX and wish to add support for running XVM as a standalone volume manager, use the following procedure:

After you have installed the software and you have quit the inst interface, you are prompted to reboot the system and apply the changes.