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.
13.2 Extend Existing Logical Volumes
Quick Answer: Ensure the VG has free space (
vgs), runlvextendon the existing LV, then grow the file system:xfs_growfsfor XFS orresize2fsfor ext4. Verify withlvsanddf -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
/databy 2G and make the space available to the file system.” - “Grow
vgapp/lvlogsto 5G total.” - “Add free VG space to the LV mounted at
/var/lib/app.”
This is not the same as:
lvcreatea 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
| Layer | What grows | Tools |
|---|---|---|
| Volume group free PE | Pool of free extents | vgextend if more PVs needed |
| Logical volume | Block device size seen by the FS | lvextend, lvresize |
| File system | Usable space in df | xfs_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:
- Which LV path backs the mount (
/dev/vg/lvor/dev/mapper/vg-lv). - FSTYPE (xfs vs ext4)—chooses the grow tool.
- How much VFree the VG has.
- 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
| FSTYPE | After lvextend |
|---|---|
xfs | xfs_growfs /mountpoint |
ext4 | resize2fs /dev/vg/lv |
vfat | Not 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)
| Check | Expect |
|---|---|
lvs | New LV size matches task |
vgs | VFree decreased by roughly the growth |
df -h on mount | Size increased (not only lvs) |
| Mount still works | findmnt, existing files still present |
| Data intact | ls 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
- LV extended, FS not grown —
dfunchanged; runxfs_growfs/resize2fs. xfs_growfs /dev/vg/lvconfusion — prefer the mounted path for XFS grow.resize2fson XFS — wrong tool.lvextend -L 2Gwhen LV is already 5G — absolute 2G is smaller → error; use+2Gor a larger absolute.- No VG free space — extend VG first; do not wipe other LVs.
- Extending the wrong LV — always map mount → SOURCE with
findmnt. - Recreate with lvcreate instead of extend — loses the “existing” volume requirement.
- Running mkfs after lvextend — data loss.
- Shrinking by accident with
lvresizenegative sizes—avoid unless explicitly required and FS supports it. - 100%FREE too early when two LVs both need growth—plan both sizes first.
Relationship to neighboring skills
| Skill | Relationship |
|---|---|
| Create LV | Makes a new volume; extend grows an old one |
| Add PV/VG capacity | Feeds free PE so extend can succeed |
| mkfs / mount | Done at LV birth; extend assumes FS already exists |
| fstab UUID | Usually 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.
You extended an XFS logical volume mounted at /data with lvextend -L +2G. df -h /data still shows the old size. What is missing?
mkfs.xfs on the LV to rebuild the superblock at the new size
xfs_growfs /data (grow the XFS file system to use the new LV space)
vgreduce of the only PV so LVM recalculates capacity
Changing the UUID in fstab before any grow tool will run
Which command best adds all remaining free extents in the VG to LV /dev/vgapp/lv1 before you grow the file system?
lvcreate -l 100%FREE -n lv1 vgapp
mkfs.ext4 -e 100%FREE /dev/vgapp/lv1
umount -a && wipefs -a /dev/vgapp/lv1
lvextend -l +100%FREE /dev/vgapp/lv1
An ext4 file system sits on /dev/vgdata/records. After a successful lvextend, which tool grows that ext4 file system?
resize2fs /dev/vgdata/records
xfs_growfs /dev/vgdata/records only, because all RHEL LVs are XFS
parted resizepart on the LV path
swapon -a on the LV
vgs shows VFree 0 on vgdata, but the task requires growing lvdata by 5G. What should you do first?
lvextend -L +5G anyway and ignore errors
lvremove every LV in vgdata to free PE, then recreate blank volumes
Add capacity to the VG (for example pvcreate on a new disk/partition and vgextend vgdata), then lvextend and grow the file system
xfs_growfs alone, which invents 5G without LVM free space
Sections you finish are checked off in the contents.