Expand RHEL LVM after a storage volume grows

The storage team increases a volume from 4 TiB to 8 TiB. lsblk sees the larger disk. Your application still sees 4 TiB in df -h. This is usually a question of which storage layer has grown.

The chain in this example is a remote NVMe namespace, a partition, an LVM physical volume (PV), an LVM logical volume (LV), and an XFS filesystem. Each layer must be checked in order.

The example device names are placeholders. Identify the actual namespace, partition, VG, LV, filesystem, and mount point before modifying anything. Protect the data with a verified backup or supported snapshot. Confirm that the storage volume and host support online expansion.

1. Inspect every layer#

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINTS
pvs
vgs
lvs -o lv_name,vg_name,lv_size,devices
df -hT

Example of the mismatch:

nvme1n1          7.9T  disk
└─nvme1n1p1      4.0T  part
  └─nvme--storage-nvme--lv 4.0T lvm /nvme-storage

Here, the host sees the expanded device. The partition still ends at 4 TiB. Increasing only the PV cannot add capacity beyond the partition boundary.

2. Expand the partition#

First, confirm the partition number and the starting sector. You are extending the ending boundary, not recreating the partition.

parted /dev/nvme1n1 unit s print free

For a GPT disk with a single LVM partition and free capacity at the end, parted can extend partition 1 to the end of the device:

parted -s /dev/nvme1n1 resizepart 1 100%
partprobe /dev/nvme1n1
lsblk -o NAME,SIZE,TYPE

If partprobe reports that the device is busy, inspect the kernel's partition view and plan a controlled reboot if necessary. Do not assume the new partition table is active until lsblk and the kernel report the expected size. Other partition layouts need a different procedure.

3. Resize the LVM physical volume#

pvresize /dev/nvme1n1p1
pvs
vgs

The PFree field should now show usable free extents in the volume group. If PFree is still zero, recheck the partition size and PV identity.

4. Extend the logical volume#

The following command assigns all remaining free extents in that VG to the target LV. Confirm that this allocation is intended.

lvextend -l +100%FREE /dev/nvme-storage/nvme-lv
lvs

A larger LV is only part of the job. df -h may still show the old filesystem size because the filesystem has its own metadata and size.

5. Grow the filesystem#

For XFS, grow the mounted filesystem by giving xfs_growfs the mount point:

findmnt /nvme-storage
xfs_growfs /nvme-storage

For ext4, use resize2fs against the correct logical-volume block device. Verify its filesystem type first:

findmnt -no FSTYPE,SOURCE /nvme-storage
# Only if FSTYPE is ext4:
resize2fs /dev/nvme-storage/nvme-lv

Never run filesystem-creation commands such as mkfs as part of an expansion. XFS can grow while mounted. Check the operational requirements of the filesystem and volume configuration before changing it.

6. Verify the result#

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINTS
pvs
vgs
lvs
df -hT /nvme-storage

You should see the new size at every intended layer. A capacity gap now points to a specific object, rather than to a vague "storage problem."

The repeatable lesson#

Track boundaries independently: namespace, partition, PV, LV, filesystem. This makes the procedure easier to verify and helps isolate failures in systems that use remote storage.

References: Red Hat LVM management and Red Hat XFS growth procedure.