LVM Fundamentals, Snapshots, and Volume Growth

1. LVM separates physical placement from logical consumption

Logical Volume Manager inserts a device-mapper allocation layer between block devices and filesystems. One or more physical volumes contribute extents to a volume group. Administrators allocate those extents to logical volumes, which appear as block devices and can hold filesystems, swap, databases, or other consumers.

flowchart TB
  A["Disk or partition"] --> PV1["Physical volume"]
  B["Disk or partition"] --> PV2["Physical volume"]
  PV1 --> VG["Volume group: shared extent pool"]
  PV2 --> VG
  VG --> LV1["Logical volume: app"]
  VG --> LV2["Logical volume: logs"]
  VG --> TP["Thin pool"]
  TP --> TLV["Thin logical volume"]
  LV1 --> FS1["Filesystem and mount"]

The mapping is flexible, but the layers remain real. Extending a logical volume does not always extend the filesystem inside it, and adding a disk to a volume group does not allocate its space to any workload until an LV changes.

2. Inspect LVM as both topology and capacity

# Compact summaries
sudo pvs
sudo vgs
sudo lvs

# Explicit fields for operational reports
sudo pvs -o pv_name,pv_uuid,vg_name,pv_size,pv_free,pv_attr
sudo vgs -o vg_name,vg_uuid,vg_size,vg_free,pv_count,lv_count,vg_attr
sudo lvs -a -o lv_name,vg_name,lv_path,lv_size,segtype,pool_lv,origin,data_percent,metadata_percent,lv_attr

# Map device-mapper layers to mounts
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
findmnt --real

Always record VG free, LV type, pool utilization, filesystem type, and mount point. Thin pools have separate data and metadata capacity; either reaching exhaustion can cause severe workload impact. Monitoring only the virtual size of thin volumes is insufficient.

3. Extents are the unit of allocation

A volume group divides usable capacity into physical extents, commonly 4 MiB by default. Logical volumes receive logical extents mapped onto those physical extents. Approximate planning is straightforward:

# Show extent size and counts
sudo vgs -o vg_name,vg_extent_size,vg_extent_count,vg_free_count,vg_free

# A safe arithmetic example: 12,800 free extents at 4 MiB each
free_extents=12800
extent_mib=4
printf 'Approximate free capacity: %s MiB\n' "$((free_extents * extent_mib))"

4. Grow from the outside inward, then verify from the inside outward

A common growth path is cloud disk or SAN LUN → kernel device → partition → LVM physical volume → logical volume → filesystem → application. Not every system uses every layer, but skipping a present layer leaves capacity unavailable.

# Illustrative commands only—replace nothing until all identities are verified.
# sudo growpart /dev/nvme0n1 3
# sudo pvresize /dev/nvme0n1p3
# sudo lvextend -L +20G /dev/vg0/app
# sudo resize2fs /dev/vg0/app          # ext4
# sudo xfs_growfs /srv/app             # XFS, run on mount point

# Some environments use lvextend -r to invoke filesystem growth.
# Validate support and failure semantics before relying on it.
# sudo lvextend -r -L +20G /dev/vg0/app

5. Snapshots preserve a point-in-time block view, not an independent backup

A classic LVM snapshot stores original blocks as the origin changes. Its allocated copy-on-write area must absorb change volume. If it fills, the snapshot becomes invalid. Snapshots also share the same failure domain as the volume group and do not protect against loss of the underlying storage.

Thin snapshots share blocks in a thin pool and are efficient initially, but pool data and metadata must be monitored. Application consistency is separate: a crash-consistent snapshot may still require database recovery, while an application-consistent snapshot coordinates flushing, freezing, or backup APIs.

# Inspect snapshots, origins, and pool pressure
sudo lvs -a -o lv_name,vg_name,origin,segtype,lv_size,data_percent,metadata_percent,lv_attr

# Example workflow only; use a disposable lab and application-consistency plan.
# sudo lvcreate --snapshot --name app-before-change --size 5G /dev/vg0/app
# sudo lvs -o lv_name,origin,data_percent,lv_attr
# ...perform and validate the change...
# sudo lvremove /dev/vg0/app-before-change

6. Hands-on lab: produce an LVM growth decision record

This lab is read-only. It works on systems with or without LVM and produces a runbook skeleton instead of modifying capacity.

lab="$HOME/devops-academy/linux/chapter10/lesson04"
mkdir -p "$lab"
cd "$lab"

target_path=${1:-/}
{
  echo '=== target ==='
  printf 'path=%s\n' "$target_path"
  findmnt --target "$target_path" -o TARGET,SOURCE,FSTYPE,OPTIONS
  df -hT "$target_path"
  echo
  echo '=== block topology ==='
  lsblk -o NAME,PATH,TYPE,SIZE,FSTYPE,MOUNTPOINTS
  echo
  echo '=== LVM ==='
  if command -v pvs >/dev/null 2>&1; then
    sudo pvs -o pv_name,vg_name,pv_size,pv_free,pv_attr 2>&1 || true
    sudo vgs -o vg_name,vg_size,vg_free,vg_extent_size,vg_free_count,vg_attr 2>&1 || true
    sudo lvs -a -o lv_path,lv_size,segtype,origin,pool_lv,data_percent,metadata_percent,lv_attr 2>&1 || true
  else
    echo 'LVM tools not installed.'
  fi
} > current-state.txt

cat > growth-runbook.md <<'EOF'
# Storage growth runbook

## Scope
- Application/path:
- Change owner:
- Maintenance window:

## Current mapping
- Mount point:
- Filesystem type:
- LV / partition / device:
- VG free capacity:
- Snapshot or backup evidence:

## Planned layer changes
1. External device:
2. Partition (if present):
3. Physical volume:
4. Logical volume:
5. Filesystem:

## Verification
- lsblk:
- pvs/vgs/lvs:
- findmnt:
- df:
- application health:

## Stop conditions and recovery
-
EOF

printf 'Created %s and %s\n' "$PWD/current-state.txt" "$PWD/growth-runbook.md"

7. Common LVM mistakes

8. Knowledge check

9. Summary

LVM pools physical extents and allocates them to logical block devices. Safe growth identifies every layer, confirms free capacity, extends from outside inward, grows the filesystem with its native tool, and verifies in reverse. Snapshots are temporary change instruments whose capacity and consistency must be actively managed.

10. Further reading

• pvs(8), vgs(8), lvs(8), pvresize(8), lvextend(8), and lvmthin(7).
• ext4 resize2fs and XFS xfs_growfs documentation.
• Storage-provider procedures for online device and partition growth.