Rocky Linux LVM: Minimal Design & Operational Guide

LVM on Rocky Linux lets you create flexible, resizable storage by abstracting physical disks into volume groups and logical volumes. This guide covers the minimal design, operational checks, failure modes, and when to modify the layout.

The Problem: Static Partitioning Constraints

Traditional disk partitioning binds a filesystem to a fixed physical sector range. When a /var/ or /home partition fills up, expanding it typically requires unmounting the drive, moving adjacent partitions, or adding a new disk and migrating data manually. This creates operational downtime and increases the risk of data loss during partition table manipulation.

The solution is Logical Volume Management (LVM), which introduces a virtualization layer between the physical disk and the filesystem. The primary takeaway is that LVM allows you to resize volumes on the fly and span a single filesystem across multiple physical disks without reformatting.

The Smallest Suitable Design

For a standard Rocky Linux server, the most efficient LVM architecture follows a three-tier hierarchy: Physical Volumes (PV), Volume Groups (VG), and Logical Volumes (LV). The minimal viable setup involves a single disk partitioned into a boot partition (standard partition) and an LVM container.

Physical Volume (PV): The raw block device (e.g., /dev/sdb) initialized for LVM use.
Volume Group (VG): A storage pool created by combining one or more PVs. This acts as the virtual disk.
Logical Volume (LV): A slice of the VG that acts as the actual mountable block device for the filesystem.

Example Configuration

To implement this design on a secondary disk /dev/sdb with root privileges, execute the following sequence:

# 1. Initialize the physical disk
pvcreate /dev/sdb

# 2. Create a Volume Group named 'vg_data'
vgcreate vg_data /dev/sdb

# 3. Create a Logical Volume named 'lv_data'
lvcreate -L 10G -n lv_data vg_data

# 4. Format the filesystem (XFS is default in Rocky)
mkfs.xfs /dev/vg_data/lv_data

# 5. Mount the volume
mkdir /data
mount /dev/vg_data/lv_data /data

Trust and Data Boundaries

Data boundaries are maintained via filesystem-level permissions on LVs, while the LVM metadata resides in a reserved header on the PV. LVM adds a layer of complexity to the boot process, requiring the initramfs to load LVM drivers to mount the root filesystem.

Operational Checks

To monitor free space and volume health, use the following command-line tools:

pvs: Displays physical volume status and usage percentage.
vgs: Shows volume group capacity and available free space.
lvs: Lists logical volume sizes and fragmentation levels.

Failure Modes and Design Changes

Primary failure modes include metadata corruption or physical disk failure. It is critical to note that LVM is not a redundancy tool by itself; to protect data from physical disk failure, you must use RAID or external backups.

Design changes are triggered when storage requirements exceed the maximum size of the current VG, necessitating the addition of new PVs to the group.

Critical Cautions: XFS Resizing

Expanding a filesystem after expanding an LV requires filesystem-specific tools. However, reducing the size of XFS volumes is not supported. If you need to shrink an XFS volume, you must backup the data, delete the LV, and recreate it.

Verification

To verify your implementation is working, attempt to extend a logical volume and check the capacity:

# 1. Extend the logical volume
lvextend -L +5G /dev/vg_data/lv_data

# 2. Grow the underlying XFS filesystem
xfs_growfs /data

# 3. Verify the result
df -h /data

Check /etc/fstab to ensure LVs are mapped correctly via device mapper paths.