Expanding LVM Logical Volumes Without Downtime

The classic storage panic, the disk is full and the service is falling over, has a calm, pre-planned answer on any LVM-managed Linux host. Because LVM sits between your disks and your filesystems, you can grow a filesystem that is mounted and busy, without unmounting, without rebooting, and without a maintenance window. The whole job is three commands, and knowing them turns a 3 a.m. incident into a two-minute fix. This guide walks the layer cake and grows a real data volume start to finish.

The LVM layer cake

Three layers make LVM tick: physical volumes (PVs) are the raw disks or partitions you hand to LVM, volume groups (VGs) are pools built from one or more PVs, and logical volumes (LVs) are the slices cut from a VG that actually carry filesystems. To grow anything you grow the layer beneath it first: extend a PV into its free space, the VG picks the space up, and only then does the LV and its filesystem get widened.

Inventory before you touch anything

Start from facts. These four commands show every layer and end with the two numbers that matter: free space in the volume group and usage on the filesystem.

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
pvs
vgs
lvs
df -h /srv/data

Write down the VG free space before you begin; it is the ceiling for every grow until you add more disk.

Step 1: grow the physical volume

The most common case on a VPS is the panel or its API adding disk to the virtual device the root volume group already sits on. The partition table has been widened already, so you only need to tell LVM the PV is bigger:

partprobe /dev/sda || true
pvresize /dev/sda2
pvs

After pvresize, the vgs output shows the new free space. If you see nothing, stop and re-check that the underlying allocation actually changed, because lvextend will correctly refuse to grow a VG that has no headroom, and that refusal is your friend.

Step 2: grow the logical volume and its filesystem

Ignore the temptation to run lvextend and resize2fs as separate steps. The -r flag makes lvextend resize the filesystem right after the LV grows, in the same call, and it knows the filesystem-specific command automatically:

lvextend -r -L +20G /dev/vg0/data
lvs
df -h /srv/data

That is the entire online grow for both ext4 and XFS. The mounted filesystem sees the new size immediately, with no unmount and no downtime. If the VG runs dry because another LV ate the pool, lvextend refuses unambiguously, which is exactly the failure mode you want to discover in a dry run rather than on a Tuesday evening.

Grow-by-percentage and thin pools

• lvextend -r -l 80%VG /dev/vg0/data sizes the LV to 80 percent of the whole volume group in one move.
• lvextend -r -l +100%FREE /dev/vg0/data grows into all remaining free space in one shot.
• On images that use thin pools the LV grow is identical; the distinction lives only in the VG free-space accounting, and vgs free still shows the honest number.

Both forms are atomic and safe to run while the filesystem is live, which is the point of doing this with LVM at all.

Shrinking is a different sport

Nothing online-shrinks safely by default. Resizing a filesystem smaller must be done offline, after defragmenting or at least quiescing the workload, and XFS cannot shrink at all. Treat grow online, shrink in a maintenance window as the rule, and prefer re-architecting over shrinking: move the data to a fresh, correctly sized LV instead of fighting the old one. The effort you save by never needing to shrink is a good argument for leaving 25 percent headroom in the first place.

Takeaway

pvresize, then lvextend -r, is the entire no-downtime grow, and combined with a df check it turns out-of-space alerts into a solved playbook rather than an incident. Netbay's High-Speed SSD and API make this easy to test, resize a disk, watch pvs report the new space, and extend an LV live at netbayhosts.in.