RHEL LVM, Swap and Safe Storage Growth

Anil Jalela · Published Sep 3, 2026 · 8 min read

LVM separates application storage from physical placement, which makes growth and replacement easier only when each layer is understood. Extending a logical volume changes the block device; growing the filesystem is a separate operation unless a reviewed command deliberately combines them. Reducing capacity is much riskier and may be impossible for the filesystem. Swap is emergency and workload memory capacity, not a universal performance defect to disable.

Map capacity at every LVM layer

A physical volume contributes extents to a volume group. Logical volumes allocate those extents and expose block devices. Filesystems allocate their own structures inside an LV. Free space in the volume group is not filesystem free space, and extending an LV without growing its filesystem does not make additional file capacity visible.

LVM snapshots use copy-on-write storage and must have enough capacity for changed blocks. They are not independent backups: loss of the origin or underlying storage affects them, and a full snapshot becomes unusable. Use snapshots for bounded consistency workflows only when the application and backup design support them.

Track capacity from memory to persistent data

Grow an LVM-backed filesystem safely

1. Resolve the application mount. Map mountpoint to filesystem, LV, VG and physical devices.
2. Confirm available and recoverable capacity. Check VG free extents, platform allocation and backup/restore state.
3. Forecast the requested size. Leave capacity for other owned volumes and operational needs.
4. Extend the exact LV. Use an explicit size or increment and capture before/after metadata.
5. Grow the filesystem with its supported tool. XFS grows while mounted; ext4 growth follows its supported state and tooling.
6. Accept and monitor. Verify capacity, application writes, latency, backup coverage and alert thresholds.

Inspect LVM, filesystems and swap pressure

pvs -o pv_name,pv_uuid,vg_name,pv_size,pv_free
vgs -o vg_name,vg_uuid,vg_size,vg_free
lvs -a -o lv_path,lv_uuid,vg_name,lv_size,lv_attr,devices,data_percent,metadata_percent
findmnt -T /srv/application
df -hT /srv/application
lsblk -f
swapon --show --output=NAME,TYPE,SIZE,USED,PRIO
free -h
vmstat 1 5
cat /proc/pressure/memory
lvextend --test -L +10G /dev/vgapp/lvdata
xfs_growfs /srv/application

• The lvextend --test example performs a dry-run style metadata check; it cannot prove the later filesystem operation or workload impact.
• Do not run the growth commands until the exact LV, mount and backup are verified. Replace sample names deliberately.
• Swap used is not the same as active swap pressure. Inspect paging rate, memory pressure, latency and workload behavior over time.
• For thin pools, monitor both data and metadata percentages. Exhausting either can disrupt multiple logical volumes.

Evidence and acceptance criteria

Worked scenario: LV extended but application still reports full

An operator extends an LV by 100 GB and sees the larger block device in lvs, but df and the application show no new capacity. The filesystem was never grown. Repeating lvextend consumes more VG space without addressing the missing layer.

The team maps the mount to the exact LV, identifies XFS, verifies the backup and runs xfs_growfs against the mounted filesystem. It records filesystem capacity and application write evidence, then updates monitoring and backup forecasts. The incident runbook now requires proof at every layer.

Practical how-to cases

sudo pvcreate /dev/vdc
sudo vgcreate vgapp /dev/vdc
sudo lvcreate -L 4G -n lvdata vgapp
sudo mkfs.xfs /dev/vgapp/lvdata
sudo mkdir -p /srv/app
sudo mount /dev/vgapp/lvdata /srv/app
pvs; vgs; lvs -a -o +devices

df -hT /srv/app
vgs vgapp
sudo lvextend --test -L +2G /dev/vgapp/lvdata
sudo lvextend -L +2G /dev/vgapp/lvdata
sudo xfs_growfs /srv/app
df -hT /srv/app

sudo lvcreate -L 1G -n lvswap vgapp
sudo mkswap /dev/vgapp/lvswap
sudo swapon /dev/vgapp/lvswap
swapon --show
free -h
sudo blkid /dev/vgapp/lvswap

sudo lvcreate -s -L 1G -n lvdata_snap /dev/vgapp/lvdata
lvs -o lv_name,origin,lv_size,data_percent,metadata_percent
sudo mkdir -p /mnt/snap
sudo mount -o ro,nouuid /dev/vgapp/lvdata_snap /mnt/snap
findmnt /mnt/snap

Independent practice tasks

1. Extend an ext4 LV with the correct filesystem step.
2. Move extents from one disposable PV to another.
3. Create two swap devices with explicit priorities and prove selection.
4. Trigger snapshot growth in a lab and monitor the failure boundary.

For this lesson on RHEL LVM and Swap Administration, complete each task without copying the worked command sequence. Record the initial state, exact change, verification, negative test and recovery command. A task is unfinished if it works now but does not survive a reboot where persistence is required.

Troubleshooting by symptom

Unsafe operations and recovery boundaries

• Unsafe: lvreduce can truncate live filesystem data. Never reduce without filesystem support, offline procedure, exact mapping and tested backup.
• Unsafe: swapoff without enough available memory can trigger severe reclaim or OOM kills. Measure headroom and workload behavior.
• Unsafe: treating an LVM snapshot as the only backup ties recovery to the same origin and storage failure domain.

Rewritten knowledge checks

Guided lab and acceptance test

1. Create loop-backed disposable devices or attach a lab disk; record exact identity.
2. Create a PV, VG and small LV, then format it with XFS and mount by UUID.
3. Write sample data and capture PV/VG/LV/filesystem capacity.
4. Extend the LV first and observe that filesystem capacity has not changed.
5. Grow XFS, verify data and capacity, and monitor the layered evidence.
6. Add a small lab swap LV, observe it with swapon, then remove all lab mappings in dependency order.

Primary references

• RHEL 10 configuring and managing logical volumes
• RHEL 10 documentation
• RHEL 9 documentation