Growing an LVM Volume by Absorbing Another Disk

When an LVM-backed filesystem fills up and its volume group (VG) has no free extents, you can grow it by adding a second physical disk as a new physical volume (PV), extending the VG onto it, then extending the logical volume (LV) and its filesystem. With ext4 this can be done online — no unmount, no downtime for the volume being grown.

This guide covers the common case where the disk you want to absorb is currently in use by its own LVM volume (you must evacuate and tear that down first), and the precautions that keep it safe.

[!warning] This enlarges your failure domain A single LV spanning two disks linearly (the default — no RAID/mirror) means losing either disk loses the entire volume. ext4 has no parity. Only do this for data you can rebuild, or layer redundancy (mdadm/LVM RAID) underneath. Back up anything irreplaceable first.

The Short Answer

If the target disk (/dev/sdX) is already empty and unused:

sudo pvcreate /dev/sdX
sudo vgextend myvg /dev/sdX
sudo lvextend -l +100%FREE /dev/myvg/mylv
sudo resize2fs /dev/mapper/myvg-mylv      # ext4, online; use xfs_growfs for XFS

The rest of this article handles the harder case: the target disk is currently holding its own LVM volume with data on it.

Step-by-Step

1. Survey the current layout

sudo pvs                       # physical volumes → which VG each belongs to
sudo vgs                       # volume groups, free extents (VFree)
sudo lvs                       # logical volumes and sizes
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
df -h

Confirm:

The VG you want to grow (myvg) has 0 VFree (that's why you're here).
The disk you want to absorb (/dev/sdX) is a standalone PV — not a member of an mdadm array, a mergerfs branch, or a SnapRAID parity disk. Repurposing a disk that something else depends on will break that thing silently.

2. Evacuate the disk you're about to absorb

Anything on the target disk will be destroyed. Move it somewhere with room to spare, then prove the copy is intact before you trust it.

# Copy preserving permissions/timestamps
sudo rsync -a /mnt/olddisk/important /destination/with/space/

# Verify byte-for-byte — empty output + exit code 0 means identical
sudo diff -rq /mnt/olddisk/important /destination/with/space/important && echo OK

For large trees the diff -rq (full byte comparison) is slow but is the authoritative check — don't skip it before the destructive phase. If an application tracks files by path (databases, media servers), update its path references to the new location now, while the old copy still exists as a fallback.

3. Unmount and remove the old disk from fstab

sudo fuser -m /mnt/olddisk          # confirm nothing holds it open
sudo umount /mnt/olddisk
mountpoint -q /mnt/olddisk && echo "STILL MOUNTED" || echo "unmounted"

sudo cp /etc/fstab /etc/fstab.bak-$(date +%Y%m%d)   # always back up fstab
sudo sed -i '/olddisk/d' /etc/fstab                 # remove the stale entry
grep olddisk /etc/fstab || echo "fstab line gone"

[!tip] Verify your sed pattern only matches the line you mean A too-broad pattern can delete the wrong fstab entry. Check the file before and after, and keep the backup until you've confirmed the system still boots.

4. Tear down the old disk's LVM

sudo lvremove -y /dev/oldvg/oldlv
sudo vgremove -y oldvg
sudo pvremove -y /dev/sdX        # wipes the LVM label off the disk

This is the point of no return for the old disk's data — which is why steps 2–3 verified the copy first.

5. Add the disk to the target VG and extend

sudo pvcreate -y /dev/sdX
sudo vgextend myvg /dev/sdX
sudo lvextend -l +100%FREE /dev/myvg/mylv

lvs/vgs should now show the LV grown to span both disks and 0 free extents.

6. Grow the filesystem (online)

# ext4 — works while mounted
sudo resize2fs /dev/mapper/myvg-mylv

# XFS — grows online too, but takes the mountpoint, not the device
sudo xfs_growfs /mountpoint

resize2fs is idempotent — if it gets interrupted, just run it again; it reports "Nothing to do!" once the filesystem already fills the LV.

7. Verify

df -h /mountpoint     # should reflect the new larger size
sudo pvs              # /dev/sdX now listed under myvg
sudo vgs myvg         # two PVs, larger VSize

Notes & Gotchas

Online resize works for the volume being grown, not the one being removed. The disk you absorb must be unmounted and torn down; the destination LV stays mounted throughout.
resize2fs interruption is safe. ext4 online resize is journaled; re-run it.
macOS cruft on evacuated disks. Trees touched by macOS often carry ._* AppleDouble files and .DS_Store — harmless to drop, but they inflate file counts in diff/rsync output. Don't mistake them for real data.
Check SMART on a disk you're promoting into a bigger role. A disk with a pending-sector history is riskier once it's in the critical path for a whole multi-disk volume than it was holding a small isolated one.
Mountpoint cleanup. After the old disk is gone, its former mountpoint directory may reappear (it was shadowed by the mount). rmdir it if empty. Note ls -A exits 0 on an empty directory, so don't gate cleanup on its exit status — test contents explicitly.

SnapRAID & MergerFS Storage Setup — add redundancy/parity instead of a linear span
mdadm — Rebuilding a RAID Array After Reinstall

5.8 KiB Raw Permalink Blame History Unescape Escape