28 June, 2009


General Notes on the concept:

The following link provides a comprehensive description of the fundamental ideas behind LVM

IBM Tutorial

Following the (excellent) discussion above, LVM is an interesting solution because it offers the following possibilities:

  • In multiple disk installations, it offers the possibility of having filesystems larger than any of the disks
  • Add disks/partitions to your disk-pool and extend existing filesystems online
  • Replace two 80GB disks with one 160GB disk without the need to bring the system offline or manually move data between disks
  • Shrink filesystems and remove disks from the pool when their storage space is no longer necessary
  • Perform consistent backups using snapshots (more on this later in the article)
  • This as we see below is not that big of a deal as long as one has a thorough understanding of the concepts.
    All this flexibility comes at a small added complexity in the sense that one has to properly describe the abstraction using CLI commands.
    The LVM is structured in three elements:
    • Volumes: physical and logical volumes and volume groups
    • Extents: physical and logical extents
    • Device mapper: the Linux kernel module


    Linux LVM is organized into:

    • physical volumes (PVs),

    • volume groups (VGs), and

    • logical volumes (LVs).

    Physical volumes are physical disks or physical disk partitions (as in /dev/hda or /dev/hdb1). A volume group is an aggregation of physical volumes. And a volume group can be logically partitioned into logical volumes.

    Figure 1: Physical-to-logical volume mapping

    Physical to logical volume mapping


    In order to do the n-to-m, physical-to-logical volumes mapping, PVs and VGs must share a common quantum size for their basic blocks; these are called physical extents (PEs) and logical extents (LEs). Despite the n-physical to m-logical volume mapping, PEs and LEs always map 1-to-1. The
    following image illustrate this concept.

    Physical to logical extent mapping

    Different extent sizes means different VG granularity. For instance, if you choose an extent size of 4GB, you can only shrink/extend LVs in steps of 4GB. Of importance is also the extent allocation policy. LVM2 doesn't always allocate PEs contiguously; for more details, see the Linux man page on lvm. The system administrator can set different allocation policies, but that isn't normally necessary, since the default one (called the normal allocation policy) uses common-sense rules such as not placing parallel stripes on the same physical volume.

    Device Mapper
    When creating VGs and LVs, you can give them a meaningful name (as opposed to the previous examples where, for didactic purposes, the names VG0, LV0, and LV1 were used). It is the Device mapper's job to map these names correctly to the physical devices. Using the previous examples, the Device mapper would create the following device nodes in the /dev filesystem:
    • /dev/mapper/VG0-LV0
    with /dev/VG0/LV0 a link to the above.
    Note: Many distributions provide utilities to partition using LVM and/or RAID. RedHat has a very nice tool, but I will be using
    Ubuntu (since I very much prefer the apt-package management system). In Ubuntu, the alternate installation CD has
    partman and support for LVM/RAID... But this does not offer much flexibility in setting extent sizes, stripe sizes, etc. So I will be
    using the CLI to do much of the partitioning. Also note that LVM (and RAID) support must be included in the initrd for the
    system to be able to boot from an LVM volume. Ubuntu does this automatically, from version 9.04, what you need though is
    the server edition.


    1. IBM Tutorial , Logical Volume Management
    2. LVM-HOWTO, LVM Howto

    No comments: