This article has multiple issues. Please help talk page. (Learn how and when to remove these template messages)( or discuss these issues on the Learn how and when to remove this template message)
|Original author(s)||Heinz Mauelshagen|
2.02.176 / 3 November 2017
In Linux, Logical Volume Manager (LVM) is a device mapper target 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.
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.
devices/multipath_component_detection=1is set in
lvm.conf. This prevents LVM from activating volumes on an individual path instead of the multipath device.
lvchange --raidminrecoveryrateto maintain acceptable I/O performance while rebuilding a LV that includes RAID functionality.
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.
clvmd, which is in constant contact with other
clvmddaemons in the cluster and can communicate a desire to get a lock on a particular set of objects.
clvmdby 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).
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:
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:
To move an online logical volume between PVs on the same Volume Group, use the "pvmove" tool:
These device mapper operations take place transparently, without applications or file systems being aware that their underlying storage is moving.
vgconvert --pvmetadatacopies. If the LVM can not read a proper header using the first copy, it will check the end of the volume for a backup header. Most Linux distributions keep a running backup in
/etc/lvm/backup, which enables manual rewriting of a corrupted LVM head using the
Manage research, learning and skills at defaultlogic.com. Create an account using LinkedIn to manage and organize your omni-channel knowledge. defaultlogic.com is like a shopping cart for information -- helping you to save, discuss and share.