Original author(s) | Heinz Mauelshagen |
---|---|
Stable release |
2.02.160 / 6 July 2016
|
Written in | C |
Operating system | Linux |
License | GNU GPL |
Website | sources |
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.
Heinz Mauelshagen wrote the original LVM code in 1998, 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.
The Ganeti solution stack relies on the Linux Logical Volume Manager.
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.
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.