13.2 Extend Existing Logical Volumes

Key Takeaways

  • Extending an existing LV is two layers: grow the LV with lvextend (or lvresize), then grow the file system with xfs_growfs (XFS) or resize2fs (ext4).
  • Confirm free space in the volume group first (vgs VFree); if the VG is full, vgextend with a new PV before lvextend.
  • XFS grows online via xfs_growfs on the mountpoint; ext4 commonly uses resize2fs on the device (often online when mounted on modern RHEL—verify success with df).
  • lvextend -r can resize the FS in one step when supported for that FS; know both combined and explicit two-step methods for EX200.
  • Extending is non-destructive growth of an existing volume—do not confuse it with lvcreate of a new LV or with deleting/recreating the LV.
Last updated: August 2026

13.2 Extend Existing Logical Volumes

Quick Answer: Ensure the VG has free space (vgs), run lvextend on the existing LV, then grow the file system: xfs_growfs for XFS or resize2fs for ext4. Verify with lvs and df -h. Extending keeps data; recreating the LV does not.

Official skill

Under Create and configure file systems, EX200 expects you to extend existing logical volumes. Typical tasks:

  • “Extend the logical volume that backs /data by 2G and make the space available to the file system.”
  • “Grow vgapp/lvlogs to 5G total.”
  • “Add free VG space to the LV mounted at /var/lib/app.”

This is not the same as:

  • lvcreate a brand-new LV (add storage non-destructively),
  • Only creating partitions,
  • Shrinking (rarely requested; XFS shrink is not a normal path).

You grow capacity in place and keep the file system and data.

Mental model: two sizes must match intent

LayerWhat growsTools
Volume group free PEPool of free extentsvgextend if more PVs needed
Logical volumeBlock device size seen by the FSlvextend, lvresize
File systemUsable space in dfxfs_growfs, resize2fs

If you only lvextend and forget FS grow, lvs looks bigger but df -h stays small—a classic incomplete exam answer.

If you only try xfs_growfs without extending the LV, growth has nowhere to go.

Step 0 — Inventory

findmnt /data
df -h /data
sudo lvs -o name,vg_name,lv_size,lv_path
sudo vgs -o name,size,free
sudo pvs
lsblk -f
blkid $(findmnt -no SOURCE /data)

Know:

  1. Which LV path backs the mount (/dev/vg/lv or /dev/mapper/vg-lv).
  2. FSTYPE (xfs vs ext4)—chooses the grow tool.
  3. How much VFree the VG has.
  4. Whether the task wants +2G additional or resize to a final size.

Ensure the VG has free space

sudo vgs
# VG  #PV #LV #SN Attr VSize  VFree
# vgdata 1   1   0  wz--n- 20.00g 5.00g

If VFree is enough for the requested growth, proceed to lvextend.

If VFree is too small:

# New partition or disk already prepared as PV
sudo pvcreate /dev/sdd1
sudo vgextend vgdata /dev/sdd1
sudo vgs

Do not lvremove existing volumes to “make free space” for an extend task.

Extend the logical volume: lvextend

Add a relative size

sudo lvextend -L +2G /dev/vgdata/data
sudo lvextend -L +512M /dev/mapper/vgdata-data

Set an absolute size

sudo lvextend -L 10G /dev/vgdata/data
# grows up to 10G total (must be larger than current)

Use extents / free pool

sudo lvextend -l +100%FREE /dev/vgdata/data
sudo lvextend -l +50%FREE /dev/vgdata/data

+100%FREE consumes all remaining VG free PE for that LV—valid when the task says use all free space; leave free PE if another LV must grow later.

lvresize

sudo lvresize -L +1G /dev/vgdata/data

lvresize can extend or (dangerously) shrink with other flags. For EX200 growth tasks, lvextend communicates intent clearly.

Combined LV + FS resize (-r / --resizefs)

sudo lvextend -r -L +2G /dev/vgdata/data

On supported setups, -r runs the appropriate FS grow after extending the LV. Still verify with df -h. If -r fails or you are unsure of FS type support in the moment, use the explicit two-step method below—it always shows clear intermediate state for troubleshooting.

Grow the file system

XFS — xfs_growfs

XFS is grown while mounted, targeting the mountpoint (not only the raw device habit from some ext tools):

# LV already extended
findmnt /data
sudo xfs_growfs /data
# or:
sudo xfs_growfs -d /data
df -h /data

Unmounted XFS growth is not the normal RHEL admin path you practice for exams—keep it mounted, extend LV, xfs_growfs.

ext4 — resize2fs

sudo lvextend -L +2G /dev/vgdata/data
sudo resize2fs /dev/vgdata/data
df -h /data

On modern RHEL, online resize of mounted ext4 is commonly supported; if the tool demands offline, unmount first, resize2fs, remount—read the error message. Prefer the path that succeeds and leaves data intact.

# Offline pattern only if required
sudo umount /data
sudo e2fsck -f /dev/vgdata/data   # often recommended before offline shrink; for grow, follow man/error guidance
sudo resize2fs /dev/vgdata/data
sudo mount /data

For grow tasks, online resize2fs after lvextend is the usual happy path.

Matching tool to TYPE

FSTYPEAfter lvextend
xfsxfs_growfs /mountpoint
ext4resize2fs /dev/vg/lv
vfatNot a typical LVM data grow path on EX200; tasks almost always use XFS/ext4 on LVs
lsblk -f /dev/vgdata/data
blkid /dev/vgdata/data

Wrong tool → confusing errors. Do not run xfs_growfs on ext4.

Full exam sequences

Scenario A — Add 2G to XFS /data

Task: The volume group has free space. Extend the LV for /data by 2 GiB and make space available.

findmnt /data
# SOURCE: /dev/mapper/vgdata-data
sudo vgs
sudo lvextend -L +2G /dev/vgdata/data
sudo xfs_growfs /data
df -h /data
sudo lvs /dev/vgdata/data

Scenario B — ext4 LV grow with -r

sudo lvextend -r -L +1G /dev/vgapp/lvdb
df -h /var/lib/db

If df unchanged, check whether -r ran and FS type; fall back to explicit resize2fs.

Scenario C — VG full; need more room first

sudo vgs
# VFree 0
lsblk
sudo pvcreate /dev/sdc1
sudo vgextend vgdata /dev/sdc1
sudo lvextend -L +5G /dev/vgdata/data
sudo xfs_growfs /data

Scenario D — “Resize LV to 8G total”

sudo lvs
# currently 5.00g
sudo lvextend -L 8G /dev/vgdata/data
sudo xfs_growfs /data
sudo lvs
# 8.00g

Using +8G by mistake would try to add eight more gibibytes, not set total to 8G—read + versus absolute.

Scenario E — Use all remaining free space

sudo lvextend -l +100%FREE /dev/vgdata/data
sudo xfs_growfs /data
sudo vgs
# VFree ~0

Verification (grade yourself)

CheckExpect
lvsNew LV size matches task
vgsVFree decreased by roughly the growth
df -h on mountSize increased (not only lvs)
Mount still worksfindmnt, existing files still present
Data intactls known files; no forced reformat

Optional practice reboot: LV size and FS size remain large—LVM metadata and FS geometry are on disk.

Order of operations summary

1. Identify LV + FS type + mountpoint
2. Confirm VG free space (vgextend if needed)
3. lvextend / lvresize (grow LV)
4. xfs_growfs OR resize2fs (grow FS)  — or lvextend -r if it succeeds
5. df -h + lvs verify

Never: mkfs on the LV to “apply” the new size. That destroys data and is the opposite of extend.

Stratis / VDO / thinp awareness

Stock EX200 study points emphasize classic LVM extend + FS grow. If a lab used exotic layouts, still start from findmnt, lvs, vgs. Do not introduce Stratis solely because free space is confusing—fix simple free PE first.

Common traps

  1. LV extended, FS not growndf unchanged; run xfs_growfs / resize2fs.
  2. xfs_growfs /dev/vg/lv confusion — prefer the mounted path for XFS grow.
  3. resize2fs on XFS — wrong tool.
  4. lvextend -L 2G when LV is already 5G — absolute 2G is smaller → error; use +2G or a larger absolute.
  5. No VG free space — extend VG first; do not wipe other LVs.
  6. Extending the wrong LV — always map mount → SOURCE with findmnt.
  7. Recreate with lvcreate instead of extend — loses the “existing” volume requirement.
  8. Running mkfs after lvextend — data loss.
  9. Shrinking by accident with lvresize negative sizes—avoid unless explicitly required and FS supports it.
  10. 100%FREE too early when two LVs both need growth—plan both sizes first.

Relationship to neighboring skills

SkillRelationship
Create LVMakes a new volume; extend grows an old one
Add PV/VG capacityFeeds free PE so extend can succeed
mkfs / mountDone at LV birth; extend assumes FS already exists
fstab UUIDUsually unchanged after extend—same FS UUID

UUID stability is a benefit of extend: you rarely rewrite fstab after a pure size increase.

Section checkpoint

You should map a mountpoint to its LV, confirm VG free space (extending the VG when needed), grow the LV with lvextend, grow XFS with xfs_growfs or ext4 with resize2fs (or a successful lvextend -r), and prove success with both lvs and df -h without reformatting. That is the EX200 standard for extending existing logical volumes on RHEL 10.

Test Your Knowledge

You extended an XFS logical volume mounted at /data with lvextend -L +2G. df -h /data still shows the old size. What is missing?

A
B
C
D
Test Your Knowledge

Which command best adds all remaining free extents in the VG to LV /dev/vgapp/lv1 before you grow the file system?

A
B
C
D
Test Your Knowledge

An ext4 file system sits on /dev/vgdata/records. After a successful lvextend, which tool grows that ext4 file system?

A
B
C
D
Test Your Knowledge

vgs shows VFree 0 on vgdata, but the task requires growing lvdata by 5G. What should you do first?

A
B
C
D