Right, so you’ve got a logical volume that’s running out of space. Don’t panic. This isn’t like trying to add a new room to a house while you’re still living in it. With LVM, we can do this online—while the filesystem is mounted and actively in use. It’s one of LVM’s killer features, and it works so well it feels like a party trick. The key thing to remember, and I’ll shout this until I’m blue in the face: extending the logical volume is only half the job. You’ve just bought a bigger plot of land; now you need to tell the builder (your filesystem) that it has more space to work with.

Let’s walk through the whole dance, from checking your free space to growing the FS, and I’ll point out all the places you could accidentally trip along the way.

Checking Your Current Layout

Before you type a single destructive command, know what you’re working with. Blindly resizing things is a fantastic way to have a very bad day.

# Get a overview of your volume groups and free space
sudo vgdisplay

# Or for a more concise, readable summary:
sudo vgs

Look for the VFree column in the output of vgs. That’s your available “land.” Next, identify the logical volume and its current filesystem.

# See all your logical volumes and their underlying devices
sudo lvs

# Find out what device your mounted filesystem is on (e.g., /dev/mapper/myvg-mylv)
df -h

# And crucially, check the filesystem type
lsblk -f

Why is the filesystem type so crucial? Because the command you use to resize ext4 is different from xfs, and trying to use the wrong one is like trying to fit a square peg in a round hole—it won’t work, and you’ll look silly.

Adding More Physical Space (If Needed)

You can’t extend into nothing. If your volume group has no free space (VFree is 0), you need to add a new physical volume (a new disk or partition) first.

# Let's assume you added a new disk at /dev/sdb
sudo pvcreate /dev/sdb
sudo vgextend my_volume_group /dev/sdb

Now, sudo vgs should show free space in your volume group. If you’re extending from an existing partition, you might need to resize the partition first using fdisk or parted—a slightly more nerve-wracking process I hope you have good backups for.

Extending the Logical Volume

This is the easy part. You’re telling LVM to take some of that free space in the volume group and add it to your logical volume. The -l +100%FREE option is brilliantly lazy: it means “use all the remaining free space in the VG.” You can also use -L +10G to add a specific amount.

# Extend 'my_logical_volume' to use all free space in its VG
sudo lvextend -l +100%FREE /dev/my_vg/my_lv

Boom. Done. The block device (/dev/my_vg/my_lv) is now larger. But if you run df -h again, you’ll see the filesystem size hasn’t changed. That’s because the filesystem inside it is still the same size. We’ve expanded the land but not the house.

Growing the Filesystem

This is the part that makes people nervous, but it’s straightforward if you know your filesystem type. The designers of xfs and ext4 made different choices here, which is… a choice.

For ext2/ext3/ext4: You use resize2fs. It’s smart enough to detect the new size of the underlying device, so often you can just point it at the LV and let it do its thing.

# This will expand the ext4 filesystem to fill the LV it's on
sudo resize2fs /dev/my_vg/my_lv

For XFS: This is where folks get tripped up. XFS can only be grown, not shrunk. And crucially, it must be mounted to be grown. Don’t ask me why; it’s just one of its quirks.

# The filesystem on /dev/my_vg/my_lv must be mounted somewhere, like /data
sudo xfs_growfs /data

Notice you point xfs_growfs at the mount point, not the device. It’s a weird syntax until you get used to it.

The Absolute Worst Pitfall

The most common, heart-stopping mistake is doing these steps out of order. You must extend the LV first, then the filesystem. Trying to resize a filesystem to be larger than its underlying block device is a recipe for catastrophic corruption. The tools are usually smart enough to stop you, but don’t count on it.

The other edge case? If you’re using an LVM-thin pool, the process is different—you’re dealing with virtual allocation, not physical. But that’s a story for another section. For now, enjoy your newly expanded storage. Just remember: with great power comes the great responsibility to always, always check your vgs and df -h output twice.