Logical Volume Manager (Linux)

Appearance move to sidebar hide Logical Volume Manager
Original author(s)Heinz Mauelshagen
Stable release2.03.21 Edit this on Wikidata / 21 April 2023 (21 April 2023)
Written inC
Operating systemLinux, NetBSD

In Linux, Logical Volume Manager (LVM) is a device mapper framework that provides logical volume management for the Linux kernel. Most modern Linux distributions are LVM-aware to the point of being able to have their root file systems on a logical volume.

Heinz Mauelshagen wrote the original LVM code in 1998, when he was working at Sistina Software, taking its primary design guidelines from the HP-UX's volume manager.


LVM is used for the following purposes:

LVM can be considered as a thin software layer on top of the hard disks and partitions, which creates an abstraction of continuity and ease-of-use for managing hard drive replacement, repartitioning and backup.


Various elements of the LVM

Basic functionality

Advanced functionality


High availability

The LVM also works in a shared-storage cluster in which disks holding the PVs are shared between multiple host computers, but can require an additional daemon to mediate metadata access via a form of locking.

CLVM A distributed lock manager is used to broker concurrent LVM metadata accesses. Whenever a cluster node needs to modify the LVM metadata, it must secure permission from its local clvmd, which is in constant contact with other clvmd daemons in the cluster and can communicate a desire to get a lock on a particular set of objects. HA-LVM Cluster-awareness is left to the application providing the high availability function. For the LVM's part, HA-LVM can use CLVM as a locking mechanism, or can continue to use the default file locking and reduce "collisions" by restricting access to only those LVM objects that have appropriate tags. Since this simpler solution avoids contention rather than mitigating it, no concurrent accesses are allowed, so HA-LVM is considered useful only in active-passive configurations. lvmlockd As of 2017, a stable LVM component that is designed to replace clvmd by making the locking of LVM objects transparent to the rest of LVM, without relying on a distributed lock manager. It saw massive development during 2016.

The above described mechanisms only resolve the issues with LVM's access to the storage. The file system selected to be on top of such LVs must either support clustering by itself (such as GFS2 or VxFS) or it must only be mounted by a single cluster node at any time (such as in an active-passive configuration).

Volume group allocation policy

LVM VGs must contain a default allocation policy for new volumes created from it. This can later be changed for each LV using the lvconvert -A command, or on the VG itself via vgchange --alloc. To minimize fragmentation, LVM will attempt the strictest policy (contiguous) first and then progress toward the most liberal policy defined for the LVM object until allocation finally succeeds.

In RAID configurations, almost all policies are applied to each leg in isolation. For example, even if a LV has a policy of cling, expanding the file system will not result in LVM using a PV if it is already used by one of the other legs in the RAID setup. LVs with RAID functionality will put each leg on different PVs, making the other PVs unavailable to any other given leg. If this was the only option available, expansion of the LV would fail. In this sense, the logic behind cling will only apply to expanding each of the individual legs of the array.

Available allocation policies are:


Basic example of an LVM head Inner workings of the version 1 of LVM. In this diagram, PE stands for a Physical Extent.

Typically, the first megabyte of each physical volume contains a mostly ASCII-encoded structure referred to as an "LVM header" or "LVM head". Originally, the LVM head used to be written in the first and last megabyte of each PV for redundancy (in case of a partial hardware failure); however, this was later changed to only the first megabyte. Each PV's header is a complete copy of the entire volume group's layout, including the UUIDs of all other PVs and of LVs, and allocation map of PEs to LEs. This simplifies data recovery if a PV is lost.

In the 2.6-series of the Linux Kernel, the LVM is implemented in terms of the device mapper, a simple block-level scheme for creating virtual block devices and mapping their contents onto other block devices. This minimizes the amount of relatively hard-to-debug kernel code needed to implement the LVM. It also allows its I/O redirection services to be shared with other volume managers (such as EVMS). Any LVM-specific code is pushed out into its user-space tools, which merely manipulate these mappings and reconstruct their state from on-disk metadata upon each invocation.

To bring a volume group online, the "vgchange" tool:

  1. Searches for PVs in all available block devices.
  2. Parses the metadata header in each PV found.
  3. Computes the layouts of all visible volume groups.
  4. Loops over each logical volume in the volume group to be brought online and:
    1. Checks if the logical volume to be brought online has all its PVs visible.
    2. Creates a new, empty device mapping.
    3. Maps it (with the "linear" target) onto the data areas of the PVs the logical volume belongs to.

To move an online logical volume between PVs on the same Volume Group, use the "pvmove" tool:

  1. Creates a new, empty device mapping for the destination.
  2. Applies the "mirror" target to the original and destination maps. The kernel will start the mirror in "degraded" mode and begin copying data from the original to the destination to bring it into sync.
  3. Replaces the original mapping with the destination when the mirror comes into sync, then destroys the original.

These device mapper operations take place transparently, without applications or file systems being aware that their underlying storage is moving.


See also


  1. ^ a b "LVM README". 2003-11-17. Retrieved 2014-06-25.
  2. ^ " v2_03_21 annotated tag has been created". 21 April 2023. Retrieved 22 April 2023.
  3. ^ "7.1.2 LVM Configuration with YaST". SUSE. 12 July 2011. Archived from the original on 25 July 2015. Retrieved 2015-05-22.
  4. ^ "HowTo: Set up Ubuntu Desktop with LVM Partitions". Ubuntu. 1 June 2014. Archived from the original on 4 March 2016. Retrieved 2015-05-22.
  5. ^ "9.15.4 Create LVM Logical Volume". Red Hat. 8 October 2014. Retrieved 2015-05-22.
  6. ^ "BTRFS performance compared to LVM+EXT4 with regards to database workloads". 29 May 2018.
  7. ^ "Tagging LVM2 Storage Objects". Micro Focus International. Retrieved 21 May 2015.
  8. ^ "The Metadata Daemon". Red Hat Inc. Retrieved 22 May 2015.
  9. ^ "Using LVM's new cache feature". 22 May 2014. Retrieved 2014-07-11.
  10. ^ "2.3.5. Thinly-Provisioned Logical Volumes (Thin Volumes)". Access.redhat.com. Retrieved 2014-06-20.
  11. ^ "4.101.3. RHBA-2012:0161 — lvm2 bug fix and enhancement update". Retrieved 2014-06-08.
  12. ^ "5.4.16. RAID Logical Volumes". Access.redhat.com. Retrieved 2017-02-07.
  13. ^ "Controlling I/O Operations on a RAID1 Logical Volume". redhat.com. Retrieved 16 June 2014.
  14. ^ "Re: LVM snapshot with Clustered VG ". 15 Mar 2013. Retrieved 2015-06-08.
  15. ^ ""vmlockd.c git history"". Archived from the original on January 4, 2024.
  16. ^ "Bug 9554 – write barriers over device mapper are not supported". 2009-07-01. Retrieved 2010-01-24.
  17. ^ "Barriers and journaling filesystems". LWN. 2008-05-22. Retrieved 2008-05-28.
  18. ^ "will pvmove'ing (an LV at a time) defragment?". 2010-04-29. Retrieved 2015-05-22.
  19. ^ "Gotchas". btrfs Wiki. Archived from the original on January 4, 2024. Retrieved 2017-04-24.

Further reading