LVM concepts - PV, VG, LV, and the storage stack · Linux

LVM (Logical Volume Manager) sits between the block device and the filesystem. It provides a layer of indirection that decouples the filesystem from the physical disk, enabling flexible resize, span across disks, and snapshots.

The storage stack

Read-only / SafeLVM stack— pvs shows physical volumes. vgs shows volume groups (one or more PVs combined). lvs shows logical volumes (the usable storage). The same physical storage appears in three different views, and the three must reconcile: 99.00g + 500.00g of PV is a 599.00g VG, of which 5 + 90 + 295 = 390.00g is allocated to LVs and 4.00g + 205.00g = 209.00g remains free. If those sums do not match, you are looking at two different volume groups.

$ pvs; echo ---; vgs; echo ---; lvs

  PV         VG   Fmt  Attr PSize   PFree
/dev/sda2  vg0  lvm2 a--   99.00g   4.00g
/dev/sdb1  vg0  lvm2 a--  500.00g 205.00g
--- VG   #PV #LV #SN Attr   VSize   VFree
vg0    2   3   0 wz--n- 599.00g 209.00g
--- LV   VG  Attr       LSize
root vg0 -wi-ao----   5.00g
var  vg0 -wi-ao----  90.00g
data vg0 -wi-ao---- 295.00g

When to use LVM

Read-only / SafeLVM on a real host— A typical production host with LVM. Read the indentation as containment: the PV partition carries FSTYPE LVM2_member, and the LVs allocated from it are its children. Logical volumes are always SIBLINGS of one another - vg0-root and vg0-var are both children of sda2 - because an LV is carved from the volume group's extents, never from another LV. An LV shown nested inside another LV is a misread. An LV whose extents span two PVs appears under both, which is how you spot a volume that will not survive losing one disk.

$ lsblk -o name,size,type,fstype,mountpoint

NAME          SIZE TYPE FSTYPE      MOUNTPOINT
sda          100G disk
├─sda1         1G part ext4        /boot
└─sda2        99G part LVM2_member
├─vg0-root   5G lvm  ext4        /
└─vg0-var   90G lvm  ext4        /var
sdb          500G disk
└─sdb1       500G part LVM2_member
└─vg0-data 295G lvm  xfs         /data

Use LVM when:

Filesystems need to grow or shrink over time.
Storage spans multiple physical disks.
Snapshots are needed (LVM snapshots, not btrfs).
The operations team needs flexible storage management.

Do not use LVM when:

A single disk with a single fixed-size partition is enough.
The performance overhead of LVM is unacceptable (rare on modern kernels).
The team has no LVM experience and the workload is simple.

LVM commands

Data-loss riskcreate LV— pvcreate initializes a PV. vgcreate combines PVs into a VG. lvcreate allocates an LV from a VG. mkfs creates a filesystem. mount attaches the LV. The LV appears as /dev/vg_data/data.

$ pvcreate /dev/sdc1; vgcreate vg_data /dev/sdc1; lvcreate -L 100G -n data vg_data; mkfs.ext4 /dev/vg_data/data; mount /dev/vg_data/data /data

Physical volume '/dev/sdc1' successfully created.
Volume group 'vg_data' successfully created
Logical volume 'data' successfully created

Data-loss riskextend LV— lvextend grows the LV. resize2fs grows the filesystem to match. Both are online and do not require unmount. The LV size in lvs now shows 150G, the filesystem in df shows 150G.

$ lvextend -L +50G /dev/vg_data/data; resize2fs /dev/vg_data/data

Size of logical volume vg_data/data changed from 100.00g to 150.00g
resize2fs 1.47.0 (5-Feb-2023)
Resizing the filesystem on /dev/vg_data/data to 39321600 (4k) blocks.
The filesystem on /dev/vg_data/data is now 39321600 (4k) blocks long.

LVM snapshots

Configuration changeLVM snapshot— LVM snapshots use copy-on-write. The -L 5G is a FIXED allocation of copy-on-write space taken from the VG at creation time, not an initial reservation that grows. As blocks in the origin are overwritten, the original blocks are copied into that 5G. Roughly 5G of change to the origin fills it.

$ lvcreate -L 5G -s -n data-snap /dev/vg_data/data

Logical volume 'data-snap' successfully created

A classic snapshot does not grow, it dies

The dangerous belief is that -L 5G is a starting size that expands on demand. It is not. A classic (thick) LVM snapshot has a fixed copy-on-write allocation, and when that fills the snapshot is dropped to Invalid state. The origin is unharmed, but the snapshot is gone and lvconvert --merge will refuse to run. You discover this at the moment you need the rollback.

Snapshots do have an auto-extend mechanism, but it is off by default. It requires two things: dmeventd monitoring the LV (systemctl enable --now lvm2-monitor) and activation/snapshot_autoextend_threshold lowered below 100 in /etc/lvm/lvm.conf. The shipped default is 100, and the config file documents that value as “disables automatic extension”.

Size the snapshot for the change you expect, not the size of the origin. A schema migration that rewrites 40G needs more than 40G of COW space, whatever the LV size is.

Monitor the fill level for the life of the snapshot. Data% is the percentage of the COW space consumed:

Read-only / Safesnapshot fill level— Data% is the COW fill level, not the origin usage. Alert above 70%. In the lv_attr column, position 1 is 's' for a snapshot and 'o' for its origin; position 5 is the state, where 'a' is active and 'I' is INVALID. old-snap here is at 100% and already invalid: it cannot be merged and its only remaining use is lvremove.

$ lvs -o lv_name,origin,lv_size,data_percent,lv_attr vg_data

  LV         Origin  LSize    Data%  Attr
data               100.00g         owi-aos---
data-snap  data      5.00g   62.40 swi-a-s---
old-snap   data      2.00g  100.00 swi-I-s---

Illustrative output

Two operational consequences follow. First, a snapshot is a temporary object: take it, do the work, then lvremove it. A forgotten snapshot fills silently and also slows every write to the origin, because each first overwrite of a block costs an extra read and write. Second, alert on Data% the same way you alert on filesystem usage.

If you want the safety net, turn it on explicitly:

# /etc/lvm/lvm.conf
activation {
    snapshot_autoextend_threshold = 70
    snapshot_autoextend_percent = 20
}

sudo systemctl enable --now lvm2-monitor

Auto-extend can still fail if the VG has no free extents, so keep headroom in the VG. It reduces the risk; it does not remove the need to size the snapshot properly.