LVM Linux

Introduction to LVM

LVM stands for Logical Volume Manager. It is a device mapper framework in Linux that offers logical volume management for the Linux kernel. Almost every latest Linux distribution is LVM-aware to the key point of containing the root file systems in the logical volume.

In 1988, Heinz Mauelshagen specified the actual LVM code when he was operating on the Sistina Software, considering the main guidelines of its design from the volume manager of HP-UX.

Uses of LVM

LVM is used for below purposes:

• Creating individual logical volumes of two or more physical volumes or whole hard disks, permitting resizing of the dynamic volume.
• Managing farms of large hard disks by permitting disks to be included and substituted without service or downtime disruption in association with hot swapping.
• Rather than needing to estimate during installation time how large a partition might require to be on small systems, LVM permits filesystems to be resized easily as required.
• Implementing consistent backups by considering the logical volume snapshots.
• Encrypting two or more physical partitions using a single password.
  LVM can be taken as a thin layer of the software on top of the partitions and hard disks, which makes an abstraction of ease of use and continuity to manage hard drive backup, repartitioning, and replacement.

Features of LVM

Basic functionalities

• VGs (Volume groups) can be online resized by absorbing PVs (physical volumes) or eliminating existing ones.
• Logical volumes can be traveled between physical volumes.
• Logical volumes can be online resized by adding extents onto them or cutting extents from them.
• Establishment of a read-only snapshot of LVs (LVM1), leveraging a feature, i.e., a copy on write (or CoW), or read/write snapshots (LVM2).
• Volume groups can be divided and combined in situ as long as the logical volumes don't span the split. It can be helpful during migrating entire logical volumes from or to offline storage.
• Volume groups and logical volumes can be made running because the basic devices become exist using the lvmetad daemon.
• LVM objects can be titled for administrative convenience.

Advanced functionalities

• Hybrid volumes can be made with the dm-cache target. It permits one or multiple fast storage devices, like flash-based SSDs, to operate as a cache for one or multiple slower hard disk drives.
• LVM is developed using the rest of the devices mapper sufficient to avoid the single paths that return a dm-multipath device when devices/multipath_component_detection=1 is fixed inconf on newer releases of device mapper. It prevents LVM from running volumes on a single path rather than the multipath device.
• Thinly provisioned logical volumes can be provided from a pool.

RAID

• Logical volumes can be established to contain RAID functionality, such as RAID 1, 5, and 6.
• Entire logical volumes or their components can be striped around multiple physical volumes, similar to RAID 0.
• The recovery rate can be restricted using lvchange --raidminrecoveryrate and lvchange --raidmaxrecoveryrate to manage adequate I/O performance while recreating a logical volume that contains RAID functionality.
• A backend device of RAID 1 can be formed as "write-mostly", outcoming in read being ignored to such devices until necessary.

CLVM

The distributed lock manager is utilized to the metadata accesses of broker concurrent LVM. Whenever any cluster node requires to change the LVM metadata, it should protect permission through its local clvmd. In the cluster, it is in continuous contact with many clvmd daemons and can convey a desire to receive a lock on a specific object set.

High availability

Also, the LVM operates in a shared-storage cluster where disks keeping the physical volumes are shared among multiple host systems but can need an extra daemon to negotiate metadata access by way of locking.

HA-LVM

Cluster-awareness left to the app giving the high availability aspect. For part of the LVM, HA-LVM can utilize CLVM as the locking mechanism or can also continue using the default file locking mechanism and decrease "collisions" by limiting access to LVM objects that contain correct tags. As this easier solution ignores contention instead of mitigating it, concurrent accesses are not permitted, so HA-LVM is helpful in active-passive configurations only.

Lvmlockd

As of 2017, a stable component of LVM was designed to substitute clvmd by enabling the LVM object locking transparent to the whole LVM without depending on the distributed lock manager. During 2016, it saw extensive development.

The above mechanisms only solve the problems with the storage access of LVM. The file system chosen to be on top of logical volumes must support clustering via itself, or it must be mounted by an individual cluster node only.