XLV Logical Volume Planning

The following subsections discuss topics to consider when planning a logical volume.

There are some situations where logical volumes cannot be used or are not recommended:

Raw swap devices cannot be logical volumes. (However, swap space can be added as a regular file in a filesystem and that filesystem could be on a logical volume. See the guide IRIX Admin: System Configuration and Operation for more information.)
Logical volumes aren't recommended on systems with a single disk.
Striped or concatenated volumes cannot be used for the Root filesystem.

The basic guidelines for choosing which subvolumes to use with EFS filesystems are:

Only data subvolumes can be used.
The maximum size of an EFS filesystem is 8 GB, so the data subvolume shouldn't be bigger than that or the space is wasted.

The basic guidelines for choosing which subvolumes to use with XFS filesystems are:

Data subvolumes are required.
Log subvolumes are optional. If they are not used, log information is put into an internal log in the data subvolume (by giving the -l internal option to mkfs).
Real-time subvolumes are optional.

When you want a large raw partition with no filesystem on it, only the data subvolume is used.

The basic guidelines for choosing subvolume sizes are:

The maximum size of a subvolume is one terabyte on 32-bit systems (IP17, IP20, and IP22). It is unlimited on 64-bit systems (IP19, IP21, and IP26).
Choosing the size of the log (and therefore the size of the log subvolume) is discussed in the section "Choosing the Log Type and Size" in Chapter 4. Note that if you do not intend to repartition a disk to create an optimal-size log partition, your choice of an available disk partition may determine the size of the log.

The basic guidelines for plexing are:

Use plexing when high reliability and high availability of data are required.
The Root filesystem can be plexed; each plex must be a single partition volume element.
Dual-hosted logical volumes (logical volume on disks that are connected to two systems) cannot be plexed.
RAID disks should not be plexed.
Plexes can have "holes" in them, portions of the address range not contained by a volume element, as long as at least one of the plexes in the subvolume has a volume element with the address range of the hole.
The volume elements in each plex of a subvolume must be identical in size with their counterparts in other plexes (volume elements with the same address range). The structure within a volume element (single partition, striped, or multipartition) does not have to match the structure within its counterparts.
To make volume elements identical in size, use the fx command in expert mode (fx -x). At the first fx menu, give the command repartition/expert -b. This enables you to repartition in units of blocks, which will ensure that the volume element is the exact size you want it.

The basic guidelines for striping are:

The Root filesystem cannot be striped.
Applications using a striped filesystem should be using direct I/O (see the open(2) reference page).
Striped disks lead to performance improvement only when the applications that use them make large data transfers that access all of disks in the stripe in the filesystem.
Striped volume elements should be made of disk partitions that are exactly the same size. When the disk partitions are different sizes, the smallest size is used. Additional space in the larger partitions is wasted.
For best performance, each disk involved in a striped volume element should be on a separate controller. For some disk types, performance improvement is seen with up to four disks per controller. For other disk types, no additional performance improvement is seen with three or more disk.
A log subvolume can be striped only if it is an external log. Striping a log does not result in a performance improvement.

The basic guidelines for the concatenation of disk partitions are:

The Root filesystem cannot have concatenated disk partitions.
It is better to concatenate single-partition volume elements into a plex rather than create a single multipartition volume element. This is not for performance reasons, but for reliability. When one disk partition goes bad in a multipartition volume element, the whole volume element is taken offline.