Growing LVs and LVM snapshots

First, check how much space is available in the VG.

Before extending an LV you need to know the VG has free extents. LV space comes from the VG pool — if the VG is full you must either add a PV (vgextend) or shrink another LV first.

# How much is free in the VG?
sudo vgs
#   VG     #PV #LV #SN Attr   VSize    VFree
#   datavg   2   2   0 wz--n- <99.99g  30.00g
# 30 GB free — safe to extend

# More detail: free physical extents
sudo vgdisplay datavg | grep -E 'Free|Total|Alloc'
#   Total PE              25599
#   Alloc PE / Size       18176 / 71.00 GiB
#   Free  PE / Size        7423 / 29.00 GiB

# Which LV do we want to grow?
sudo lvs
#   LV      VG     Attr       LSize
#   appdata datavg -wi-ao---- 30.00g
#   logs    datavg -wi-ao---- 41.00g

# Current filesystem usage (what prompted the alarm)
df -h /mnt/appdata
# Filesystem               Size  Used Avail Use%
# /dev/mapper/datavg-appdata  30G   27G  1.4G  95%

Step 1 of growing: extend the logical volume (the block device layer).

# Extend appdata LV by 20 GB (adds to current size)
sudo lvextend -L +20G /dev/datavg/appdata
#   Size of logical volume datavg/appdata changed from 30.00 GiB to 50.00 GiB.
#   Logical volume datavg/appdata successfully resized.

# Or extend to a specific total size
sudo lvextend -L 50G /dev/datavg/appdata

# Or consume all remaining free space in the VG
sudo lvextend -l +100%FREE /dev/datavg/appdata

# After lvextend, the block device is larger but the FILESYSTEM does not know yet:
df -h /mnt/appdata
# Filesystem               Size  Used Avail Use%
# /dev/mapper/datavg-appdata  30G   27G  1.4G  95%
# <-- still shows 30 GB! The filesystem has not been told about the extra space.

lvextend only grows the block device. The filesystem sits on top and has its own size metadata — you must resize it separately.

Step 2 of growing: resize the filesystem to fill the LV.

The command differs by filesystem type:

# For ext4: resize2fs (can run on a live, mounted filesystem)
sudo resize2fs /dev/datavg/appdata
# resize2fs 1.47.0 (5-Feb-2023)
# Filesystem at /dev/datavg/appdata is mounted on /mnt/appdata; on-line resizing required
# old_desc_blocks = 4, new_desc_blocks = 7
# The filesystem on /dev/datavg/appdata is now 13107200 (4k) blocks long.

# For xfs: xfs_growfs (requires mount point, NOT device path)
sudo xfs_growfs /mnt/appdata
# meta-data=/dev/mapper/datavg-appdata isize=512    agcount=4, agsize=1966080 blks
# data     =                       bsize=4096   blocks=7864320, imaxpct=25
# ...
# data blocks changed from 7864320 to 13107200

# Verify the filesystem is now larger
df -h /mnt/appdata
# Filesystem               Size  Used Avail Use%
# /dev/mapper/datavg-appdata  50G   27G   21G  57%
# <-- now shows 50 GB

The mandatory order: lvextend first, then filesystem resize. If you try to resize2fs on a device that is smaller than the filesystem expects, it errors. If you run lvextend but forget resize2fs, the filesystem continues using the old size — the extra space exists but is invisible to the OS.

Shortcut: lvextend -r (resize flag) tells LVM to run resize2fs or xfs_growfs automatically after extending:

sudo lvextend -L +20G -r /dev/datavg/appdata
# Extends LV and resizes filesystem in one command

LVM snapshots: copy-on-write point-in-time views.

An LVM snapshot creates a point-in-time view of a logical volume. It does not copy the data immediately — instead it uses copy-on-write (COW): blocks are copied to the snapshot only when the original LV changes them. This makes snapshot creation instantaneous.

# Create a 5 GB snapshot of appdata (the COW buffer)
# The snapshot size is NOT the size of the data — it is how much change you expect during backup
sudo lvcreate -s -L 5G -n appdata-snap /dev/datavg/appdata
#   Logical volume "appdata-snap" created.

sudo lvs
#   LV           VG     Attr       LSize Origin  Snap%  Move Log
#   appdata      datavg owi-aos---  50.00g
#   appdata-snap datavg swi-a-s---   5.00g appdata   0.00
# 'o' = origin, 's' = snapshot, Snap% = how full the COW buffer is

# Mount the snapshot read-only for backup
sudo mkdir /mnt/snap
sudo mount -o ro /dev/datavg/appdata-snap /mnt/snap

# Run backup against the consistent snapshot (original LV keeps serving traffic)
sudo rsync -av /mnt/snap/ /backup/appdata-$(date +%Y%m%d)/

# Clean up: unmount and remove the snapshot
sudo umount /mnt/snap
sudo lvremove /dev/datavg/appdata-snap

The snapshot fill trap: a full snapshot becomes invalid.

The COW buffer (the size you gave to lvcreate -s) must absorb every block that changes on the origin LV between snapshot creation and removal. If more data changes than the buffer can hold, the snapshot fills up and becomes invalid.

# Watch snapshot utilisation — monitor this during a long backup
sudo lvs /dev/datavg/appdata-snap
#   LV           Snap%
#   appdata-snap 73.41  <-- 73% used, still safe

# If it hits 100%:
#   appdata-snap 100.00  <-- INVALID — data is gone from the snapshot
# Any attempt to read from it will return I/O errors

# Set a monitoring threshold: warn at 80%
# LVM can auto-extend snapshots (add to /etc/lvm/lvm.conf):
# snapshot_autoextend_threshold = 80
# snapshot_autoextend_percent = 20
# (LVM daemon lvmetad/lvmpolld will then extend automatically)

# Size the COW buffer conservatively:
# - For a busy database during a long backup: 20-30% of origin size
# - For a quiet filesystem during a quick rsync: 5-10% is fine
# - When in doubt, bigger is safer — unused COW space is wasted but not harmful