Logical Volume Manager — AIX Flavor

The 10 free filesystem space was introduced in the Berkeley UNIX. It has to be specified when the filesystem is created. It can be disabled at any time during the life of the filesystem. The reserved space can be returned for regular use at any time. The opposite is not possible: there is no way to introduce the 10 free space in an existing filesystem. If needed, the filesystem must be recreated, whatever it takes.

6.3 Logical Filesystem Layout

The physical approach to managing disk space is easier to understand, but it carried a number of restrictions caused by the disk hardware itself: How to overcome the finite size of a disk unit? What to do when the maximum size of the filesystem is below that needed? How to provide redundancy? And many other issues needed to improve overall system performances. The problem was especially acute in the management of large databases. A solution was found in a different, logical approach in managing disk space. Existing physical storage entities partitions and disks could be combined and presented as arbitrary large logical storage entities. They then appear simply as storage entities to the operating system. The obvious benefits of such an approach are its inherent flexibility and increased capabilities. For a better understanding of the terminology, here are a few introduction notes. Generally, the term physical refers to a real situation — what something physically looks like. The term logical refers to the way something is presented to the users. The relationship between physical and logical entities must be strictly defined and established. Once this bidirectional relationship is done, further management can be completely shifted to the logical layer. The required division of the storage space continues over the logical entities in the almost identical way we have already discussed. Of course, in real life everything is mapped back to physical entities, because they are the real providers of the needed storage space. The basic logical entity was named the logical volume although this name is not used explicitly on all UNIX platforms. The most common name for the whole suite is the logical volume manager LVM. UNIX vendors do not have a uniform approach regarding the LVM. There are several mutually incompatible versions designed by different manufacturers. We cannot even discuss BSD−like and System V−like versions; simply, the LVM appeared much later. LVM is a new, vendor−flavored product. This section briefly covers three LVM versions: AIX, HP−UX, and Solaris. It should be sufficient to help us become familiar with this important topic. However, it is fair to mention that the third−party vendor VERITAS is probably the leading designer in this field. As a matter of fact, VERITAS also contributed a great deal to all three of the versions examined. The terminology used by the different vendors is also very vendor−specific. The same entities are named in different ways, making a complete description quite confusing. Unfortunately, issues that are already complex enough sometimes sound even more complicated due to the naming ambiguities.

6.3.1 Logical Volume Manager — AIX Flavor

AIX started early the trend toward a logical approach to disk treatment. Since AIX 3.1, physical volumes correspond to the physical partition were divided into a large number of relatively small disk chunks by default their size was 4 MB. They were called physical partitions, but we will use 154 First, a logical partition in IBM terminology or a logical chunk has to be created. A logical chunk is the basic, smallest data storage unit for users. It corresponds to the single, double, or triple physical chunks. Multiple physical chunks can store the same, mirrored data. Storage of the same data on several physical locations significantly increases the reliability of the filesystem. Defined logical chunks are then used to create other logical entities. Although the logical chunks are presented continuously to the users, in reality their physical chunks could be discontinuous, expended, or replicated. Each physical volume is associated and identified with the appropriate special device file. Several physical volumes can be combined into a single volume group, which is then handled as a unique logical entity. To make it clear, a volume group can be compared to the physical disk unit, but now not restricted to the single disk drive. In that way, an equivalent large logical disk can include several physical disks. It can now be processed as a single large unit instead of multiple smaller units. Therefore, all restrictions related to the limited size of a single disk have been overcome. Once the volume group was created it could be divided partitioned into several smaller logical volumes. The new entity can be compared to the already known disk partition. But a single logical volume can be spread over several physical volumes that make the same volume group. It can occupy an arbitrary number of logical chunks correspondingly, a number of physical chunks on any of those physical volumes. This possibility of using disk chunks in an arbitrary way brought a new level of flexibility, and presented a big advantage over the traditional UNIX approaches. This situation is presented in Figure 6.6. 155 Figure 6.6: AIX data storage organization. The LVM provides the necessary physical−to−logical mapping and vice versa and handles filesystems. Although very complex mapping and processing is going on, everything is hidden from the users. They simply use the available storage units. 156 AIX Traditional UNIX approach Physical volume Diskpartition as an accessible physical entity Disk chunk partition None Logical chunk partition None Volume group Disk as a storage space Logical volume Partition AIX introduced new commands and utilities to work with the newly introduced entities: For volume groups mkvg Create a new volume group from one or more physical disks varyonvg Activate a created volume group varyoggvg Deactivate a created volume group extendvg Add a new disk to an existing volume group chvg Change certain volume group characteristics reducevg Remove a disk from an existing volume group importvg Add an existing volume group to the system data base exportvg Remove an existing volume group from the system data base • For logical volumes mklv Create a logical volume extendlv Increase the size of a logical volume chlv Change certain logical volume characteristics lslv List data about logical volumes rmlv Delete an existing logical volume • The existing AIX menu−driven SMIT utility system management interface tool also supports LVM in managing storage resources. Once logical volumes are defined and created, we should proceed with the filesystem creation. This procedure is more or less the same as we have discussed. There is an AIX version of the well−known UNIX command mkfs, as well as the AIX−specific front−end command crfs an AIX counterpart to the usual UNIX command newfs. Other UNIX commands to manage filesystems are also available. AIX introduced a new filesystem named journaled filesystem jfs, as its default filesystem. In the jfs each data transaction in the filesystem is temporarily recorded until its successful completion. It explains the origin of the name for the filesystem: a journaling is associated with each data transaction. If the transaction fails, old data can easily be restored from the journal. The jfsis more robust but also more expensive — an overhead in processing is related to the continuous journaling. 157 The LVM is a standard subsystem for managing disk space on the HP−UX platform. It started with HP−UX 9.04 and continues with HP−UX 10.x and HP−UX 11.x releases. With the optional support software, it offers other value−added features such as striping, or mirroring, or high availability. LVMs allow the user to consider the disks, also known as physical volumes PVs, as a pool of data storage consisting of equal−sized physical extends PEs — the default size is 4 MB. One or more PVs are grouped into volume groups VGs, which then represent the basic unit of the data storage. VGs can be subdivided into virtual disks, called logical volumes LVs. An LV consists of an arbitrary number of logical extends LEs — each LE corresponds to one PE or several PEs, if mirroring is implemented. An LV can span a number of PVs, or it can represent only a portion of a single PV. Once created, the LVs can be treated just like the disk partitions. LVs could be assigned to the filesystems, used as swap or dump devices, or used for the raw access. In that light, a functional relationship between HP−UX LVM entities and the traditional UNIX ones is: HP−UX Standard UNIX approach Physical volume Diskpartition as an accessible physical unit Physical extend None Logical extend None Volume group Disk as a storage space Logical volume Partition LVM provides a number of specific commands to create, display, and manage LV entities: To manage LVs lvchange Change LV characteristics lvcreate Create an LV in a VG lvdisplay Display information about LVs lvextend Increase space mirrors for LVs lvlnboot Prepare root, swap, and dump LV lvrmboot Remove an LV link to root, swap, or dump partition lvmigrate Migrate root filesystem from a partition to an LV lvreduce Decrease number of PEs allocated to LV lvremove Remove LVs from VG lvmerge Merge two LVs into one VG lvsplit Split mirrored LV into two LVs lvsync Synchronize stale mirrors in an LV • To manage VGs vgchange Set VG availability vgcreate Create VG vgdisplay Display information about VGs vgexport Export a VG and associated LVs vgextend Extend a VG by adding physical volumes vgimport Import a VG into the system • 158 vgremove Remove VG from the system vgscan Scan PVs for VGs vgcfgbackup Backup the VG configuration data vgcfgrestore Restore the VG configuration from backed−up data vgsync Synchronized stale LV mirrors in VGs To manage PVs pvchange Change PV characteristics pvcreate Create initialize PVs for use in volume group pvdisplay Display information about PVs pvmove Move allocated PEs between PVs • The basic steps in using LVM include: Identify the disks to be used, and create corresponding PVs — create an LVM data structure on each specified disk: pvcreatedevrdskc0t0d0 a selected disk is identified by the device file c0t0d0 1. Create a new VG — create a corresponding special device file and collect all PVs for the new VG the supposed name vg01: mkdir devvg01 mknod devvg01group c 64 0x03000 the minor number for a VG must be unique among all VGs on the system vgcreate devvg01 devdskc0t0d0 supposedly the VG includes a single PV vgdisplay −v devvg01 to check the newly created VG 2. Create LVs within the created VG: lvcreate −L 100 −n lvol1 devvg01 100 MB LV named lvol1 3. 159 lvdisplay devvg01lvol1 to check the newly created LV If there are more LVs, this step should be repeated: lvcreate −L 500 −n lvol2 devvg01 500 MB LV named lvol2 lvcreate −L 200 −n lvol3 devvg01 ....... 200 MB LV named lvol3 Any operation typical for the disk partition is also allowed on the LV. To use an LV to hold a filesystem, the corresponding filesystem must be created and mounted: newfs devvg01rlvol1 mkdir mnt_dir1 mount devvg01lvol1 mnt_dir1 4. HP−UX flavored LVM is discussed in greater detail in the case study in Chapter 27.

6.3.3 Logical Volume Manager — Solaris Flavor