http://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux)

Logical Volume Manager (Linux)

From Wikipedia, the free encyclopedia

"Logical Volume Manager" redirects here. It is not to be confused with logical volume manager.

Linux Logical Volume Manager
Original author(s)	Heinz Mauelshagen
Stable release	3.12.4 (8 December 2013; 1 day ago)[±]^[1]
Preview release	3.13-rc3(6 December 2013; 3 days ago) [±]^[2]
Written in	C
Operating system	Linux
License	GNU GPL
Website	kernel.org

LVM is a logical volume manager for the Linux kernel; it manages disk drives and similar mass-storage devices. The term "volume" refers to a disk drive or partition thereof. It was originally written in 1998 by Heinz Mauelshagen, who based its design on that of the LVM in HP-UX.

The installers for the Arch Linux, CrunchBang, CentOS, Debian, Fedora, Gentoo, Mandriva, MontaVista Linux, openSUSE,Pardus, Red Hat Enterprise Linux, Slackware, SLED, SLES, Linux Mint, and Ubuntu distributions are LVM-aware and can install a bootable system with a root filesystem on a logical volume.

[hide]

Common uses[edit]

LVM is commonly used for the following purposes:

Managing large hard disk farms by allowing disks to be added and replaced without downtimes and services disruption, in combination with hot swapping.
On small systems (like a desktop at home), instead of having to estimate at installation time how big a partition might need to be in the future, LVM allows file systems to be easily resized later as needed.
Performing consistent backups by taking snapshots of the logical volumes.
Creating single logical volumes of multiple physical volumes or entire hard disks (somewhat similar to RAID 0, but more similar to JBOD), allowing for dynamic volume resizing.
the Ganeti solution stack relies on the Linux Logical Volume Manager

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, re-partitioning, and backup.

Features[edit]

The LVM can:

Resize volume groups online by absorbing new physical volumes (PV) or ejecting existing ones.
Resize logical volumes (LV) online by concatenating extents onto them or truncating extents from them.
Create read-only snapshots of logical volumes (LVM1).
Create read-write snapshots of logical volumes (LVM2).
Create RAID logical volumes (since recent LVM implementations, such as Red Hat Enterprise Linux v6 [1]): RAID1, RAID5, RAID6, etc.
Stripe whole or parts of logical volumes across multiple PVs, in a fashion similar to RAID 0.
Mirror whole or parts of logical volumes, in a fashion similar to RAID 1.
Allocate thin-provisioned logical volumes from a pool [2]
Move online logical volumes between PVs.
Split or merge volume groups in situ (as long as no logical volumes span the split). This can be useful when migrating whole logical volumes to or from offline storage.

The LVM will also work in a shared-storage cluster (where disks holding the PVs are shared between multiple host computers), but requires an additional daemon to propagate state changes between cluster nodes.

Implementation[edit]

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

Relationship between various elements of the LVM.

LVM keeps a metadata header at the start of every physical volume, each of which is uniquely identified by a UUID. Each PV's header is a complete copy of the entire volume group's layout, including the UUIDs of all other PVs, the UUIDs of all logical volumes and an allocation map of PEsto LEs. This simplifies data recovery in the event of PV loss.

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:

Searches for PVs in all available block devices.
Parses the metadata header in each PV found.
Computes the layouts of all visible volume groups.
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:

Creates a new, empty device mapping for the destination.
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.
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.

Caveats[edit]

Until Linux kernel 2.6.31,^[3] write barriers were not supported (fully supported in 2.6.33). This means that the guarantee against filesystem corruption offered by journaled file systems like ext3and XFS was negated under some circumstances.^[4]

References[edit]

Jump up^ Kroah-Hartman, Greg (8 December 2013). "Linux 3.12.4 released". Linux kernel mailing list. Retrieved 9 December 2013.
Jump up^ Torvalds, Linus (6 December 2013). "Linux 3.13-rc3". Linux kernel mailing list. Retrieved 6 December 2013.
Jump up^ "Bug 9554 - write barriers over device mapper are not supported". 2009-07-01. Retrieved 2010-01-24.
Jump up^ "Barriers and journaling filesystems". LWN. 2008-05-22. Retrieved 2008-05-28.