| Why have multiple file systems? Most UNIX file systems allow a file to grow within the boundary of the volume on which it was created. As such, a single runaway file may completely fill a file system. A file system that is 100 percent full presents challenges to the kernel when it needs to manage the space. If file systems holding operating system directories are filled, the kernel may have difficulties performing many of its tasks and in an extreme case even crash. To avoid this scenario, most administrators prefer to create a number of individual file systems, sizing each to match its use. This allows the isolation of system directories (e.g., /usr, /lib) from user (e.g., /home) and application (e.g., /opt, /var/opt) directories. The kernel's virtual file system layer is then used to build what appears to applications and users as a single, seamless virtual file system. The kernel handles all transversal of mount points and directory structures during file open calls. Traditionally, a physical volume could hold a single file system. This meant that in order to have multiple file systems, you needed multiple physical volumes. Another limit was that the size of a file system was dependent on the size of the underlying physical volume. Early versions of HP-UX implemented a very limited form of hard disk sectioning that allowed the division of a physical disk in up to seven distinct sections. Each section could then be used to hold a file system, swap space, or raw storage. The problem with this approach was that it lacked flexibility. The sizing of the various disk sections was hardcoded in the driver and could not be adjusted by the administrator. As new disk models were created, they could not be used until the driver code was updated. Hewlett-Packard introduced LVM to address these issues (HP-UX 8.x). The basic function of the LVM subsystem (see Figure 11-1) is to combine the space of one or more physical volumes into a volume group. Once the volume group has been created, its space may be assigned to one or more logical volumes. Figure 11-1. The Logical Volume Manager 
The administrator may size the individual logical volumes to match their needs. In addition, a logical volume may be extended or reduced following its initial creation. The volume group may also be extended by adding additional physical volumes or reduced by removing physical volumes. Keep in mind that logical volume management is an entirely separate issue from file system maintenance. The LVM abstraction isolates the mechanics of the volume manager from those of the various file systems employed on HP-UX. While logical volumes and volume groups may be extended and reduced, the effects of these actions on resident file systems must be handled by file system type-specific utilities. In some cases, this may require the archiving of the file system's data and its complete recreation in order to match it to a new volume size. Care and planning must be practiced before any reconfiguration or reallocation of the physical space within a volume group is attempted. The LVM subsystem is a very robust design and greatly enhances the administrator's ability to manage the system's physical disk space. In addition to the basic sizing of logical volumes, LVM allows the optional creation of mirrored disk volumes (one-way mirroring or two-way mirroring) and volume data stripping. As you might guess, there are many issues and options the administrator needs to be aware of before attempting to manage disk space with LVM. The LVM Extent As with many kernel subsystems, LVM first divides its managed space into a fixed-size extent. While the extent size is tunable (1, 2, 4, 8, 16, 32, 64, 128, or 255 MB on a per-volume-group basis), the default 4 MB is frequently used. All of a volume group's physical volumes pool their physical extents in the group's virtual extent pool. Individual extents from this pool are mapped to a logical volume's logical extent map. LVM's Smoke and Mirrors Through the use of pseudo-device files, requests to logical volumes are directed to the LVM pseudo-driver (major number 64) in the kernel. A file system created on a logical volume is mapped to a collection of logical extents (see Figure 11-2), which in turn contain the blocks of the file system. The job of LVM is to translate a file system block number to a logical extent number and an offset within the extent. Next, it has to figure out which physical extent the logical extent maps to. Once these translations are made, the LVM pseudodriver passes the read/write request to the hardware driver responsible for the physical disk on which the mapped physical extent exists. In this manner, the offset within a logical extent is converted to an offset within a physical extent. As LVM performs these activities behind the smokescreen provided by the device switch tables, the requesting thread is blind to the redirection and translations that take place. Figure 11-2. Mapping Extents 
As a quick review, let's examine the commands required to initialize a logical volume group and create logical volumes. Building a Volume Group To create a new volume group on your HP-UX system, there are several basic steps to follow (see Figure 11-3). - First, any physical volume intended for use with LVM must be physical volume created (using the pvcreate command). This basic initialization consists of building template data structures at the beginning of the disk (see Figure 11-4). The templates used depends on whether the physical volume will be used as a bootable disk. Once a physical volume has been designated for use with LVM (pvcreated) the mkfs and newfs commands will refuse to work with it as a physical volume. Both commands have a f option to allow a forceful override of this protection mechanism.
Figure 11-4. Metadata Disk Layout 
- Second, device files must be created to allow access to the volume group and its logical volumes. This is accomplished by creating a new directory under /dev (i.e., /dev/vg01). We must also create a pseudo-device file under our new directory /dev/vg01/group. The name of our new directory is arbitrary (although the general wisdom is to start the name of the new directory with vg so that it may be easily spotted when listing the contents of /dev) but the group filename is required.
- Third, we simply create the volume group with the vgcreate command. The physical volume names passed to this command fix the order of each physical volume within the volume group. Physical disk order greatly influences the allocation order of extent resources within a volume group. Physical volumes may also be a assigned to a labeled subgroup within the overall volume group. These "physical volume groups" (PVG) come into play during the creation of mirrored extents when the strict allocation policy option is enabled. This assures that multiple mirrors of the same extent are not located on the same physical disk.
- Finally, we are ready to lvcreate our logical volumes. A volume group is kind of like a checking account: you may write a check for any amount as long as you don't overdraw the account. In general, LVM simply allocates virtual extents from its free pool. They are taken from the first available physical extent, meaning that extents from the first physical volume are used before those of the second. It should be noted that command line options allow the administrator a great deal of control over the allocation process.
Figure 11-3. LVM Administration Review 
You may notice that in Figure 11-3 the mknod command (used to create /dev/vg01/group) has a specific major and minor number. For LVM, the major number (8 bits) is always 64. The minor number contains three 8-bit sections and is usually represented as a six-digit hexadecimal number. The first two digits (8 bits) represent the volume group number. The next two digits are always set to 00, and the last two digits reflect the logical volume number. The volume group's group file is, in effect, logical volume 0 and is utilized by the LVM administrative commands to provide a path of access to the LVM metadata resident on the volume group's physical volumes. |
