Worldwide Locations
Abstract
Like many UNIX operating systems, AIX uses the concepts of Logical Volume Management (LVM) in its data management architecture. This white paper explains the specifics of the AIX LVM and provides some tips and best practice recommendations to get the most from your AIX disk storage.
Sample
Like many UNIX operating systems, AIX uses the concepts of Logical Volume Management (LVM) in its data management architecture. This white paper explains the specifics of the AIX LVM and provides some tips and best practice recommendations to get the most from your AIX disk storage.
LVM is a generalized approach to managing storage that is not specific to any operating system. All UNIX-like operating systems typically offer an LVM option; in AIX an LVM-based approach is the only way to manage storage. So understanding how AIX implements LVM is necessary for the AIX administrator.
Generally this is a good thing, however, as LVM offers a great deal of flexibility in managing storage while minimizing the need to take data out of production when restructuring is needed.
A Brief History of Logical Volumes
Permanent data storage normally uses hard disk drive (HDD), technology originally developed by IBM in the mid 1950s. Today HDDs are typically aggregated into arrays in storage appliances using various methods to provide redundancy in case of the failure of any single HDD. In this case the array, or a portion of the storage space in the array, will be presented to a client operating system as a Logical Unit (LUN). This is not yet LVM, however, as the LUN still appears to the operating system as a single, large-capacity storage device. For LVM purposes there is no functional difference between a local HDD and a LUN, so we will simply call either type of storage a disk.
LVM use arises when we consider how the client operating system is going to subdivide the space in a disk for its use. This subdivision is necessary as disk space may be needed for different things such as page space, file systems, a kernel dump device, or possibly raw data space for an application that does not want to use files to store its data.
The majority of disk space is normally used for file storage, and there are many reasons to implement multiple file systems to store data in categories that are best handled differently. Each file system will then need to have space allotted from the disks available.
Early operating systems solved this problem by disk partitioning. This involved dividing each disk into a few fixed-size partitions, whose beginning and end points were defined by a partition table written to a reserved portion of each disk. This worked, but had limitations. The size of the partition table typically limited the number of partitions to eight or less. Also, as the partition table was read and stored in memory at boot, changes to it typically required either a reboot or at least the removal of the disk from production to reconfigure it. Either case required data to go out of production. Finally, partitions could not be dynamically resized, making it necessary to try to predict how much space would be needed in a partition as time passed. This was not always easy, and resulted in partitions that were either too large or too small. In this case, restructuring of disk partition tables was necessary, disrupting production.
The 1989 release of AIXv3 introduced the mandatory use of LVM to address these limitations. Next we will examine how this introduction addressed the problems of fixed partition allocation, and then look at the specifics of the AIX LVM implementation.
The Concept of Logical Volume Management
If partition tables divide disks into a small number of large partitions, the LVM reverses this idea, dividing disks into a large number of small partitions. To distinguish the difference, LVM schemes use the term physical extent, or in the case of AIX, physical partition (PP) to describe these small units of disk space. The disk itself is called a physical volume (PV). When multiple PVs are available they can be collected into volume groups (VGs).
In the figure above, we see three disks, hdisk1, hdisk2, and hdisk3. Each disk has been divided into PPs. If we say the PP size is 1 GB, then hdisk1 and hdisk3 are 10 GB in size and hdisk2 is 8 GB. Small numbers of PPs are used here for ease of illustration. In a real system these disks would be much larger-a single disk might contain thousands of PPs.