💽 Managing LVM and Resizing Disks on Linux Without Data Loss

Disk-full at 2am is a special kind of stress, because the fix involves commands that can destroy data if you run them in the wrong order. LVM makes growing storage easy once you understand the layers — and terrifying if you don’t.

After 25 years of resizing production volumes, here’s the mental model, the exact safe command order, and where AI is a genuine safety net versus where it’ll happily walk you off a cliff.

The three layers, top to bottom

LVM is just three stacked abstractions, and every operation is “which layer am I touching”:

1. Physical Volume (PV) — a raw disk or partition: /dev/sdb1
2. Volume Group (VG) — a pool of one or more PVs: vg_data
3. Logical Volume (LV) — a slice of the VG that gets a filesystem: /dev/vg_data/lv_app

On top of the LV sits a filesystem (ext4, xfs). That’s a fourth thing you resize separately — and forgetting it is the #1 reason “I grew the disk but df still shows it full.”

See all three at once:

pvs
vgs
lvs

Or the full picture:

lsblk
vgdisplay vg_data

The golden rule: bottom-up to grow, top-down to shrink

To grow, you work from the bottom up: extend the PV, extend the LV, then grow the filesystem. To shrink, you reverse it: shrink the filesystem first, then the LV. Get this backwards on a shrink and you truncate a filesystem into space that still has data in it — instant corruption.

I shrink LVs roughly never in production. Growing is routine; shrinking is a “take a backup and a maintenance window” event.

Growing a volume online (the common case)

Say /dev/vg_data/lv_app is full and you’ve added a new disk /dev/sdc.

1. Make the new disk a PV:

sudo pvcreate /dev/sdc

2. Add it to the volume group:

sudo vgextend vg_data /dev/sdc

3. Extend the logical volume — here, use all free space:

sudo lvextend -l +100%FREE /dev/vg_data/lv_app

4. Grow the filesystem — and this depends on the filesystem type:

For ext4:

sudo resize2fs /dev/vg_data/lv_app

For xfs (online only, can’t shrink):

sudo xfs_growfs /mnt/app

Note lvextend has a shortcut that does steps 3 and 4 together:

sudo lvextend -r -l +100%FREE /dev/vg_data/lv_app

The -r resizes the filesystem for you. Convenient, but I still verify with df -h after.

Where AI helps before you hit Enter

The dangerous part of LVM isn’t the concepts, it’s getting the device path or the order wrong at 2am. Before running anything, paste your lsblk, pvs, vgs, lvs output to a model and state your intent:

“Here is my current LVM layout. I want to grow lv_app by adding the new disk /dev/sdc. Give me the exact command sequence, bottom-up, and flag anything that could lose data. Identify the filesystem type and use the correct grow command.”

The model is genuinely good at catching “you’re about to pvcreate a disk that already has a partition table” or “that LV is xfs, resize2fs will fail.” I keep a vetted version in my prompt library. This is the same read-and-reason-first pattern I use for incident triage — AI proposes, you run.

The commands that will ruin your day

These deserve a hard pause, and I never let AI talk me into one without independent verification:

• pvcreate on a disk with existing data — wipes the LVM signature region. Confirm the disk is truly empty with lsblk and wipefs -n (the -n is a dry run).
• lvreduce / resize2fs to a smaller size — shrink the filesystem first and to a size smaller than the target LV, or you corrupt it.
• vgremove / lvremove — gone is gone. Double-check the name.
• mkfs on the wrong device — the classic. Always lsblk immediately before.

AI will confidently generate any of these. Treat its destructive commands as a draft to verify against your own lsblk, never as gospel.

Always have an out

Before any resize on data you care about:

sudo lvs -o +seg_count   # know your layout
df -h                    # know your current usage

If it’s truly critical, snapshot first:

sudo lvcreate -L 5G -s -n lv_app_snap /dev/vg_data/lv_app

An LVM snapshot gives you a rollback point. Remove it when you’ve confirmed the operation succeeded, because snapshots fill up and can wedge the origin volume if they overflow.

Verify the result

After any grow, the two-command confirmation:

lvs
df -h /mnt/app

If lvs shows the new size but df doesn’t, you skipped the filesystem grow — go back to step 4.

The takeaway

LVM is four layers: PV, VG, LV, filesystem. Grow bottom-up, shrink top-down (rarely), and always resize the filesystem as a separate step. Let AI lay out the exact command sequence and flag data-loss risks against your real lsblk output — but you run every command, and you verify the destructive ones independently. Slow is smooth, smooth is fast, and intact data beats a clever one-liner every time.

AI-generated disk commands are assistive and can be destructive. Verify device paths and filesystem types against your own system before running anything.