Logical Volume Manager (Linux)

Logical Volume Manager (LVM)

Company type	Software infrastructure
Industry	Computer software, Storage management
Founded	1998
Founder	Heinz Mauelshagen
Products	Logical volume management software

Logical Volume Manager (LVM) is a device-mapper infrastructure incorporated into the Linux and NetBSD kernels, designed to offer adaptable logical volume management by abstracting underlying physical storage devices. Created in 1998 by Heinz Mauelshagen at Sistina Software, its architecture draws inspiration from the volume management system found in HP-UX. LVM enables system administrators to consolidate physical volumes (PVs) into volume groups (VGs), from which logical volumes (LVs) can be allocated, potentially spanning multiple physical disks. Logical volumes provide capabilities such as resizing, relocating, and snapshot creation while the system remains operational. Additional features include thin provisioning, caching, striping, mirroring, and RAID-like configurations. LVM is extensively integrated across contemporary Linux distributions, often forming the foundation for root filesystem configurations and delivering seamless, dynamic storage management without interrupting services.

Uses

LVM fulfills several critical business functions:

• Enabling the creation of unified logical volumes from multiple physical volumes or entire disks, allowing for flexible resizing.
• Supporting management of extensive disk arrays by permitting disk additions or replacements without system downtime, including hot swapping capabilities.
• Providing flexible filesystem resizing on smaller-scale systems without requiring precise initial partition sizing.
• Allowing reliable backup processes through logical volume snapshot functionality.
• Offering encryption across multiple physical partitions secured by a single password.

Functioning as a software abstraction layer over physical disks and partitions, LVM simplifies tasks such as drive replacement, repartitioning, and backup administration.

Basic functionality

• Volume groups (VGs) can be adjusted online by adding or removing physical volumes (PVs).
• Logical volumes (LVs) support online resizing by extending or reducing extents.
• Migration of LVs between PVs is supported.
• Read-only snapshots of LVs in LVM1 utilize copy-on-write (CoW) technology; LVM2 also supports read/write snapshots.
• VGs may be split or merged in place provided no LVs cross the split boundary—this facilitates moving LVs to or from offline storage.
• Administrative ease is enhanced through tagging of LVM objects.
• Automatic activation of VGs and LVs occurs as devices become accessible via the lvmetad daemon.

Advanced functionality

• Hybrid volumes leverage the dm-cache target to use faster storage media such as SSDs to cache data from slower hard drives.
• Thin provisioning allows allocation of LVs from a shared pool, improving overall storage efficiency.
• Compatibility with newer device mapper versions enables ignoring individual paths behind dm-multipath devices, avoiding activation conflicts when devices/multipath_component_detection=1 is enabled in lvm.conf.

RAID

• Logical volumes (LVs) are capable of incorporating RAID features such as RAID 1, 5, and 6.
• Entire LVs or segments can be striped across multiple physical volumes (PVs), resembling the behavior of RAID 0.
• A RAID 1 backend PV can be set to "write-mostly" mode to reduce read operations unless absolutely necessary.
• The speed of recovery during LV rebuild processes can be adjusted using lvchange --raidmaxrecoveryrate and lvchange --raidminrecoveryrate, helping to preserve I/O throughput.

High availability

LVM supports shared-storage cluster configurations where PVs are accessible by multiple hosts, necessitating supplementary daemons for managing metadata locking.

CLVM

Employs a distributed lock manager to synchronize simultaneous access to LVM metadata. Each node requests locks via its local clvmd, which coordinates cluster-wide locking.

HA-LVM

Depends on cluster-aware applications for locking. It can utilize CLVM locks or default file locking with limited access controlled by tags, primarily suited for active-passive environments due to the lack of concurrent access support.

lvmlockd

Introduced as a stable LVM component in 2017 intended to replace clvmd. It provides transparent locking of LVM objects without relying on a distributed lock manager, following extensive development in 2016.

While these solutions manage LVM storage concurrency, the overlying file system must either support clustering (e.g., GFS2, VxFS) or be mounted exclusively on one node at a time in active-passive setups.

Volume group allocation policy

Volume groups (VGs) within LVM employ a default allocation strategy for new logical volumes that can be modified per LV using lvconvert -A or globally on the VG via vgchange --alloc. To minimize fragmentation, LVM initially attempts the strictest allocation method (contiguous) before relaxing constraints until successful allocation occurs.

In RAID configurations, allocation policies apply independently to each RAID leg. For instance, under a cling policy, expanding the file system will avoid using PVs already assigned to other RAID legs. Since RAID LVs distribute each leg across separate PVs, expansion is limited if no additional free PVs exist. Thus, cling influences expansion on a per-leg basis.

Available allocation policies include:

• Contiguous – demands all logical extents (LEs) be sequential and ordered, reducing fragmentation but restricting growth flexibility.
• Cling – confines new LE allocations to PVs already utilized by the LV, lowering fragmentation and mitigating device failure impact.
• Normal – selects physical extents (PEs) broadly while preventing parallel RAID legs from residing on the same device.
• Anywhere – imposes no restrictions; this is risky for RAID since it disregards isolation and may increase fragmentation in linear volumes.

Implementation

Each physical volume (PV) starts with an "LVM header" that stores the complete volume group layout, including UUIDs for all PVs and LVs and maps detailing PE-to-LE assignments. Although these headers were once duplicated at both ends of the PV, they are now stored solely within the first megabyte to aid data recovery if a PV is lost.

Since Linux Kernel version 2.6, LVM functions through the device mapper, a block-level virtual device framework that simplifies kernel complexity by managing I/O redirection. The logic specific to LVM resides in user-space utilities that interpret on-disk metadata to configure mappings.

Activating a volume group with "vgchange" involves:

1. Scanning all block devices for physical volumes.
2. Reading metadata headers from detected PVs.
3. Calculating volume group layouts.
4. For each logical volume scheduled for activation:
   1. Confirming presence of all required PVs.
   2. Creating an empty device mapping.
   3. Mapping it linearly over the LV’s allocated data regions on PVs.

To migrate an active LV between PVs within the same VG, "pvmove":

1. Establishes a new device mapping at the target location.
2. Implements a "mirror" target encompassing source and destination; the kernel copies data in degraded mode during migration.
3. Switches to the new mapping after synchronization completes and removes the original mapping.

These device mapper procedures operate transparently, ensuring no disruption to running applications or file systems.

Limitations

• Prior to Linux kernel version 2.6.31, write barrier support was absent (with complete implementation arriving in 2.6.33), which compromised filesystem integrity guarantees in journaled filesystems such as ext3 and XFS under certain scenarios.
• As of 2015, there is no dedicated defragmentation utility available for LVM. Fragmentation primarily arises during volume expansions and can be alleviated through strategic allocation policies; however, manual defragmentation requires the use of pvmove to reorganize data.
• Typically, LVM configurations retain a single copy of the LVM header on each physical volume, making them more susceptible to failures at the disk sector level. This default behavior can be altered using vgconvert --pvmetadatacopies. In cases where the main header becomes unreadable, LVM attempts to locate a backup header stored at the volume's end. Additionally, most Linux distributions keep backup metadata files within /etc/lvm/backup, enabling recovery through manual execution of vgcfgrestore.

See also

• Btrfs (features native snapshot functionality; combining LVM snapshots with btrfs may lead to data loss)
• Device mapper
• Logical Disk Manager (LDM)
• Logical volume management
• Snapshot (computer storage)
• Storage virtualization
• ZFS

Further reading

• .
• .