Extend an LVM Logical Volume and Filesystem

When a filesystem on LVM runs low on space, you extend capacity in two places: the logical volume (LV) and the filesystem inside it. Search results often jump straight to lvextend, but if the volume group (VG) has no free extents you need more PV capacity first. That can mean adding another PV with pvcreate and vgextend, or running pvresize when the existing PV's underlying disk or partition has already been enlarged. The walkthrough below follows one lab on a spare 10 GiB disk so every command builds on the previous step.

If you have not built LVM stacks before, start with configure LVM in Linux for pvcreate, vgcreate, and lvcreate. Root filesystem expansion and shrinking live in a separate guide because they carry boot and rescue risk.

Quick Answer

Pick the row that matches your situation, then run the commands in order. Replace VG, LV, SIZE, and device paths with your values.

The lab walkthrough below demonstrates ext4, XFS, vgextend, and lvextend -r on a spare disk. On production hosts, follow only the filesystem and capacity path that matches df -hT.

Understand What Must Be Extended

People often say “extend the LVM partition,” but LVM uses logical volumes, not traditional disk partitions. A partition (or whole disk) can become a PV; the LV you mount is a separate layer above that.

Capacity flows through four layers before applications see free space:

lvextend only changes the LV size. The filesystem still believes it owns the old smaller area until you run a grow command. That is why df can stay unchanged right after a successful lvextend.

Set Up the Lab Environment

The examples below use a spare 10 GiB disk (/dev/sdb) on a lab VM. The system disk is /dev/sda with the rhel volume group — do not run pvcreate or wipefs on that disk.

If a previous lab run was interrupted, mount points may still be active or ext_vg may still exist. Confirm the spare disk is blank and the lab volume group is gone before you partition.

Identify the spare disk and check for an existing lab volume group:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL /dev/sdb

NAME SIZE TYPE FSTYPE MOUNTPOINTS MODEL
sdb   10G disk                    VBOX HARDDISK

Confirm the lab volume group from a prior run is gone:

sudo vgs ext_vg

Volume group "ext_vg" not found
  Cannot process volume group ext_vg

If ext_vg exists, stop and tear down the previous lab run before you repartition. Do not automatically remove a volume group by name because a non-lab system could already use that name.

Partition the spare disk into two GPT partitions named pv1 and pv2. The first partition seeds the volume group; the second stays unused until the vgextend section later in this walkthrough.

Set device variables for the spare disk and the two partitions you are about to create:

DISK=/dev/sdb
PV1=/dev/sdb1
PV2=/dev/sdb2

When ext_vg is still present from a prior run, unmount lab mount points and remove LVM layers from the top down:

for mountpoint in /mnt/lvm-extend-lab/mnt /mnt/lvm-extend-lab/mntxfs; do
  if findmnt -rn "$mountpoint" >/dev/null; then
    sudo umount "$mountpoint"
  fi
done

sudo lvremove -y ext_vg/xfs_lv ext_vg/ext_lv
sudo vgremove -y ext_vg
sudo pvremove -y "$PV1" "$PV2"

sudo wipefs -a "$DISK"

wipefs on $DISK removes GPT signatures from the whole disk after the LVM labels on $PV1 and $PV2 are gone.

wipefs -a on the whole disk removes partition-table signatures from the spare disk. It is destructive — confirm DISK is the expendable lab disk, not your OS disk. Then write a fresh GPT label and create both partitions:

sudo wipefs -a "$DISK"
sudo parted -s "$DISK" mklabel gpt
sudo parted -s "$DISK" mkpart pv1 1MiB 5GiB
sudo parted -s "$DISK" mkpart pv2 5GiB 100%

On GPT, pv1 and pv2 are partition names. GPT does not use MBR-style primary, extended, and logical partition types. The resulting device names remain /dev/sdb1 and /dev/sdb2.

Tell the kernel to re-read the partition table and wait for /dev/sdb1 and /dev/sdb2 to appear:

sudo partprobe "$DISK"
sudo udevadm settle

Because this is a dedicated destructive lab disk, clear any filesystem or LVM signatures left inside the newly recreated partition ranges. Running wipefs -a only on the whole disk removes its partition table but does not erase signatures stored inside its partitions.

sudo wipefs -a "$PV1" "$PV2"

Confirm both partition devices exist before you hand the first one to LVM:

lsblk -o NAME,SIZE,TYPE,FSTYPE /dev/sdb

NAME   SIZE TYPE FSTYPE
sdb     10G disk
├─sdb1   5G part
└─sdb2   5G part

Print the partition device paths your shell will use in later commands:

printf 'PV1=%s PV2=%s\n' "$PV1" "$PV2"

PV1=/dev/sdb1 PV2=/dev/sdb2

For interactive partitioning with size checks, see parted command in Linux.

Create mount directories for the ext4 and XFS walkthroughs:

sudo mkdir -p /mnt/lvm-extend-lab/mnt /mnt/lvm-extend-lab/mntxfs

Build the volume group on PV1 only, create a 500 MiB ext4 logical volume, format it, mount it, and seed a test file:

sudo pvcreate "$PV1"

Physical volume "/dev/sdb1" successfully created.

Register the new PV in a volume group named ext_vg:

sudo vgcreate ext_vg "$PV1"

Volume group "ext_vg" successfully created

Carve a 500 MiB logical volume for the ext4 walkthrough:

sudo lvcreate -L 500M -n ext_lv ext_vg

Logical volume "ext_lv" created.

Format the LV as ext4 before mounting:

sudo mkfs.ext4 -F /dev/ext_vg/ext_lv

mke2fs 1.47.1 (20-May-2024)
Creating filesystem with 512000 1k blocks and 128016 inodes
Filesystem UUID: 146490da-e7ff-4cbb-acc3-468e31f8b990
Superblock backups stored on blocks:
	8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409

Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

Attach the filesystem at the lab mount point:

sudo mount /dev/ext_vg/ext_lv /mnt/lvm-extend-lab/mnt

Mount succeeds with no output when the LV attaches cleanly.

echo "seed data" | sudo tee /mnt/lvm-extend-lab/mnt/keepme.txt

seed data

The lab is ready for inspection and extension. The rest of this article follows this single sequence through XFS growth, a full VG, vgextend, and lvextend -r.

Inspect Current LVM and Filesystem Size

Before you add space, record the VG name, LV path, filesystem type, and mount point.

List logical volumes in the volume group:

sudo lvs ext_vg

LV     VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  ext_lv ext_vg -wi-ao---- 500.00m

The LSize column is the LV block device size. In -wi-ao----, w means writable, a means active, and o means the device is open. Confirm that it is mounted with findmnt.

Check how much space remains in the volume group:

sudo vgs ext_vg

VG     #PV #LV #SN Attr   VSize  VFree
  ext_vg   1   1   0 wz--n- <5.00g <4.51g

VFree is the pool you can assign with lvextend. LVM reports slightly less than 5 GiB on the first partition after metadata overhead.

Confirm which PVs feed the VG:

sudo pvs

PV         VG     Fmt  Attr PSize  PFree
  /dev/sda3  rhel   lvm2 a--  28.00g     0
  /dev/sdb1  ext_vg lvm2 a--  <5.00g <4.51g

Only touch PVs that belong to the VG you intend to extend. The system rhel VG on /dev/sda3 is unrelated to this lab.

See the LV in the block tree with filesystem type and mount point:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS /dev/ext_vg/ext_lv

NAME           SIZE TYPE FSTYPE MOUNTPOINTS
ext_vg-ext_lv  500M lvm  ext4   /mnt/lvm-extend-lab/mnt

df reports what the filesystem exposes to users (slightly less than LV size after formatting overhead):

df -hT /mnt/lvm-extend-lab/mnt

Filesystem                Type  Size  Used Avail Use% Mounted on
/dev/mapper/ext_vg-ext_lv ext4  459M   15K  430M   1% /mnt/lvm-extend-lab/mnt

findmnt confirms the source device and mount options:

findmnt /mnt/lvm-extend-lab/mnt

TARGET                  SOURCE                    FSTYPE OPTIONS
/mnt/lvm-extend-lab/mnt /dev/mapper/ext_vg-ext_lv ext4   rw,relatime,seclabel

Write down the filesystem type from df -hT or lsblk -f. That decides whether you use xfs_growfs or resize2fs later.

Check Free Space in the Volume Group

lvextend draws from VFree in the volume group. If VFree is smaller than the growth you need, lvextend fails before any filesystem work runs.

Read free space and extent size:

sudo vgs -o vg_name,vg_size,vg_free,vg_extent_size,vg_free_count ext_vg

VG     VSize  VFree  Ext   Free
  ext_vg <5.00g <4.51g 4.00m 1154

On this host each physical extent is 4 MiB. Free is the extent count behind VFree. To add 200 MiB you need at least fifty free extents (200 ÷ 4).

When VFree is zero or too small:

• Run pvresize when the underlying disk or partition was enlarged outside LVM (see When the Volume Group Needs More Capacity).
• Add another blank disk or partition with pvcreate and vgextend (covered later in this lab).
• Or reduce how much you ask lvextend to add.
• Creating a new LV elsewhere does not help an existing LV on a full VG.

Extend the Logical Volume

lvextend grows the LV block device. You can add a relative size, set an absolute size, or allocate extents.

Add 200 MiB to the current LV size with -L +:

sudo lvextend -L +200M /dev/ext_vg/ext_lv

Size of logical volume ext_vg/ext_lv changed from 500.00 MiB (125 extents) to 700.00 MiB (175 extents).
  Logical volume ext_vg/ext_lv successfully resized.

Confirm the LV grew:

sudo lvs ext_vg/ext_lv

LV     VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  ext_lv ext_vg -wi-ao---- 700.00m

df still shows the old filesystem size until you grow the filesystem:

df -h /mnt/lvm-extend-lab/mnt

Filesystem                 Size  Used Avail Use% Mounted on
/dev/mapper/ext_vg-ext_lv  459M   15K  430M   1% /mnt/lvm-extend-lab/mnt

Other useful lvextend forms:

Use -L for human sizes and -l for extent arithmetic. The next section grows the filesystem to match.

Grow the Filesystem

lvextend only enlarges the LV block device. Check the filesystem type with df -hT or findmnt, then follow one subsection below.

The lab demonstrates both ext4 and XFS so you can practice each tool. On a production host, stop after the subsection that matches your filesystem type.

Grow ext4 with resize2fs

ext4 grows online with resize2fs while the filesystem is mounted in normal use. Pass the LV device path (or mapper path).

After lvextend enlarged ext_lv to 700 MiB, grow ext4 to fill the LV:

sudo resize2fs /dev/ext_vg/ext_lv

resize2fs 1.47.1 (20-May-2024)
Filesystem at /dev/ext_vg/ext_lv is mounted on /mnt/lvm-extend-lab/mnt; on-line resizing required
old_desc_blocks = 4, new_desc_blocks = 6
The filesystem on /dev/ext_vg/ext_lv is now 716800 (1k) blocks long.

Confirm the filesystem now reports the larger size:

df -h /mnt/lvm-extend-lab/mnt

Filesystem                 Size  Used Avail Use% Mounted on
/dev/mapper/ext_vg-ext_lv  646M   15K  609M   1% /mnt/lvm-extend-lab/mnt

Existing files survive the grow. The seed file from before the extension is still readable:

cat /mnt/lvm-extend-lab/mnt/keepme.txt

seed data

For ext4, offline resize is only required in unusual recovery cases. Standard administration uses online resize2fs on a mounted filesystem.

Grow XFS with xfs_growfs

XFS grows online while mounted. On RHEL 10 with xfsprogs 6.16, mkfs.xfs requires a data section of at least 300 MiB, so create the XFS logical volume at 2 GiB or larger on this lab host.

Create and format the XFS logical volume, then mount it:

sudo lvcreate -L 2G -n xfs_lv ext_vg

Logical volume "xfs_lv" created.

Format the new LV as XFS:

sudo mkfs.xfs /dev/ext_vg/xfs_lv

meta-data=/dev/ext_vg/xfs_lv     isize=512    agcount=4, agsize=131072 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=1
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=1
         =                       exchange=0   metadir=0
data     =                       bsize=4096   blocks=524288, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1, parent=0
log      =internal log           bsize=4096   blocks=16384, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
         =                       rgcount=0    rgsize=0 extents
         =                       zoned=0      start=0 reserved=0

Mount the formatted XFS volume at the second lab path:

sudo mount /dev/ext_vg/xfs_lv /mnt/lvm-extend-lab/mntxfs

Mount succeeds with no output when the LV attaches cleanly.

Extend the LV first, then grow XFS. This guide passes the mount point to xfs_growfs, which is the form Red Hat documents:

sudo lvextend -L +500M /dev/ext_vg/xfs_lv

Size of logical volume ext_vg/xfs_lv changed from 2.00 GiB (512 extents) to <2.49 GiB (637 extents).
  Logical volume ext_vg/xfs_lv successfully resized.

Grow the mounted XFS filesystem to fill the larger LV:

sudo xfs_growfs /mnt/lvm-extend-lab/mntxfs

meta-data=/dev/mapper/ext_vg-xfs_lv isize=512    agcount=4, agsize=131072 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=1
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=1
         =                       exchange=0   metadir=0
data     =                       bsize=4096   blocks=524288, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1, parent=0
log      =internal log           bsize=4096   blocks=16384, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
         =                       rgcount=0    rgsize=0 extents
         =                       zoned=0      start=0 reserved=0
data blocks changed from 524288 to 652288

The data blocks changed line confirms XFS expanded. Verify capacity with df:

df -h /mnt/lvm-extend-lab/mntxfs

Filesystem                 Size  Used Avail Use% Mounted on
/dev/mapper/ext_vg-xfs_lv  2.5G   80M  2.4G   4% /mnt/lvm-extend-lab/mntxfs

After both LVs are allocated, less free space remains on the first PV:

sudo vgs ext_vg

VG     #PV #LV #SN Attr   VSize  VFree
  ext_vg   1   2   0 wz--n- <5.00g 1.82g

XFS supports grow only. There is no supported shrink path for production XFS filesystems on Linux.

When the Volume Group Needs More Capacity

When VFree is too small for the extension you need, extend the volume group before you run lvextend again. Use pvresize when the existing disk or partition was enlarged outside LVM. Use pvcreate and vgextend when you are adding a separate disk or partition.

The lab below runs the vgextend path on a second partition. The pvresize path is the usual choice when a virtual disk or LUN was grown in place.

Grow an existing PV with pvresize

If the existing disk or partition was enlarged outside LVM — for example, after increasing a VM disk or SAN LUN — you do not need to add another PV. Enlarge the partition first when LVM sits on a partition rather than the whole disk, then make LVM aware of the new capacity.

Confirm that Linux sees the larger block device or partition with lsblk or pvs, then resize the existing PV:

sudo pvresize /dev/sdXN

Physical volume "/dev/sdb1" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized

Replace /dev/sdXN with your PV device path, such as /dev/sdb1 on this lab host.

A successful pvresize normally reports that the physical volume was changed or resized. Check that the PV grew with pvs:

sudo pvs

Then confirm the volume group picked up the extra free extents:

sudo vgs

Once VFree increases, continue with lvextend and the filesystem grow command for that LV.

pvresize changes LVM's view of an existing PV; it does not enlarge the disk or partition itself.

Add another physical volume with vgextend

When you have a separate blank disk or partition, add it to the volume group before extending the LV. Prepare the device the same way you would for a new PV in configure LVM in Linux — do not run pvcreate on disks that hold /, /boot, or another production VG.

In the lab, a 2 GiB extension on ext_lv fails once both LVs fill the first PV:

sudo lvextend -L +2G /dev/ext_vg/ext_lv

Insufficient free space: 512 extents needed, but only 467 available

Add the second partition that was created at lab setup but not yet in the volume group:

sudo pvcreate "$PV2"

Physical volume "/dev/sdb2" successfully created.

Add that PV to the existing volume group:

sudo vgextend ext_vg "$PV2"

Volume group "ext_vg" successfully extended

Verify the larger pool:

sudo vgs ext_vg

VG     #PV #LV #SN Attr   VSize VFree
  ext_vg   2   2   0 wz--n- 9.99g 6.82g

List PVs to see how free space is split across sdb1 and sdb2:

sudo pvs

PV         VG     Fmt  Attr PSize  PFree
  /dev/sda3  rhel   lvm2 a--  28.00g     0
  /dev/sdb1  ext_vg lvm2 a--  <5.00g  1.82g
  /dev/sdb2  ext_vg lvm2 a--  <5.00g <5.00g

#PV is now 2 and VFree is about 6.82 GiB (1.82 GiB left on the first PV plus nearly 5 GiB from the second). The logical volumes do not grow until you run lvextend on each LV that needs space.

Extend the LV and Filesystem in One Command

lvextend -r extends the LV and then delegates filesystem resizing through LVM's filesystem-resizing support (resize2fs for ext4, xfs_growfs for XFS when mounted). Teach the separate steps first so you know which layer failed when something goes wrong.

With free space restored, extend ext_lv by 200 MiB in one step:

sudo lvextend -r -L +200M /dev/ext_vg/ext_lv

File system ext4 found on ext_vg/ext_lv mounted at /mnt/lvm-extend-lab/mnt.
  Size of logical volume ext_vg/ext_lv changed from 700.00 MiB (175 extents) to 900.00 MiB (225 extents).
  Extending file system ext4 to 900.00 MiB (943718400 bytes) on ext_vg/ext_lv...
resize2fs /dev/ext_vg/ext_lv
resize2fs 1.47.1 (20-May-2024)
Filesystem at /dev/ext_vg/ext_lv is mounted on /mnt/lvm-extend-lab/mnt; on-line resizing required
old_desc_blocks = 6, new_desc_blocks = 8
The filesystem on /dev/ext_vg/ext_lv is now 921600 (1k) blocks long.

resize2fs done
  Extended file system ext4 on ext_vg/ext_lv.
  Logical volume ext_vg/ext_lv successfully resized.

The combined step resized both layers. Confirm the LV block device size:

sudo lvs ext_vg/ext_lv

LV     VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  ext_lv ext_vg -wi-ao---- 900.00m

Check that df matches the new filesystem capacity:

df -h /mnt/lvm-extend-lab/mnt

Filesystem                 Size  Used Avail Use% Mounted on
/dev/mapper/ext_vg-ext_lv  834M   15K  789M   1% /mnt/lvm-extend-lab/mnt

If lvextend -r fails, compare lvs and df before running another command. When lvs shows the new size but df does not, the LV grew but the filesystem resize failed; finish with resize2fs or xfs_growfs. When the LV size is unchanged, correct the original error and rerun the extension.

Verify a Production LV After Reboot

The lab above is torn down at the end of this article and is not listed in /etc/fstab. For a production data LV on persistent disks that you mount from fstab, the extension survives reboot without fstab changes.

Extending an existing LV does not change its identity. An /etc/fstab entry that mounts the LV by UUID or /dev/mapper/vg-lv path remains valid; you normally edit nothing in fstab.

Confirm the fstab line still points at the same filesystem UUID:

sudo blkid /dev/VG/LV

Match that UUID against the mount entry in /etc/fstab. After a maintenance window, reboot and check capacity:

df -hT /mount/point

The reported size should match what you set with lvextend and the grow step. The LVM extension itself is persistent, and the current RHEL workflow verifies the resulting LV and filesystem sizes after lvextend --resizefs.

The filesystem cannot return to its old size after a successful grow. If the expected size is not shown after reboot, use findmnt, lsblk -f, and lvs to confirm that the intended LV—not another filesystem—is mounted at that path.

Troubleshoot LVM Extension Problems

Command Lookup

Single commands for inspection and lookup. For full workflows, see Quick Answer at the top of this article.

References

• lvextend(8) — logical volume extension
• pvresize(8) — resize a PV after underlying storage grows
• vgextend(8) — add PV capacity to a VG
• xfs_growfs(8) — grow a mounted XFS filesystem
• resize2fs(8) — grow an ext2/ext3/ext4 filesystem
• Configuring and managing logical volumes — Red Hat Enterprise Linux 10 — extending volume groups and linear logical volumes

Summary

You walked through one lab on a spare 10 GiB disk: partition a blank disk, build a volume group on the first partition, extend logical volumes with lvextend, grow filesystems so df reflects the new capacity, and add a second partition with vgextend when the volume group runs out of extents. On production systems where the virtual disk or LUN was enlarged first, pvresize on the existing PV is the other common path to more VFree before lvextend. On ext4 the grow step is resize2fs on the LV device; on XFS it is xfs_growfs on the mount point.

The common mistake is stopping after lvextend. The LV block device grows immediately, but applications only see extra space once the filesystem metadata catches up. When lvextend -L +2G failed with only 467 free extents, the lab fix was pvcreate and vgextend on the second partition — not a different flag on the same command. On a single enlarged data disk, check whether pvresize is enough before adding another PV.

lvextend -r delegates the filesystem resize to LVM's helper, but separate steps make it easier to see which layer failed. Compare lvs and df after any partial failure before you retry. For root filesystem work or shrinking, use the dedicated root LVM guide instead of the procedures here.