Right, so you need to shrink a logical volume. You’re probably thinking, “How hard can it be? lvreduce -L-5G /dev/myvg/mylv, a quick prayer, and reboot, right?” Let’s stop you right there. That’s a fantastic way to turn your production server into a very expensive paperweight. Shrinking is the one operation in the LVM toolkit that demands respect, because you’re not just moving metadata pointers around; you’re physically chopping bits off a filesystem that probably has your data on it. We do this carefully, with the precision of a safecracker, not the gusto of a lumberjack.

The golden rule, the one I live by and you should tattoo on your brain, is this: The filesystem must be shrunk first, before the underlying logical volume. The LV is just a big, empty bucket to the filesystem. If you shrink the bucket and then tell the filesystem, the filesystem will confidently try to access parts of its disk that are no longer there. The result is catastrophic data loss and a sound you’ve probably never heard before: the quiet whimper of a sysadmin realizing they skipped the backups.

The Non-Negotiable Prerequisites

First, you absolutely must have a current backup. I’m not your manager, I’m your brilliant friend, and I’m telling you: if you don’t have a verified backup, close this book and go make one right now. This isn’t a suggestion; it’s a prerequisite for not getting fired.

Second, you need to ensure the filesystem you’re shrinking actually supports online shrinking. Most modern ones like ext4 and xfs do, but they have… opinions on how it’s done. For ext4, you can often shrink while mounted, but I’m a paranoid old soul and prefer to do it offline for a operation this critical. For XFS, I have some bad news: you cannot shrink an XFS filesystem at all. It’s a design choice. They built it to grow, not to shrink. If you have an XFS volume, your only option is to back up the data, destroy the LV, create a smaller one, and restore. It’s a pain, but it’s the only safe way.

The Step-by-Step Safecracker’s Guide

Let’s walk through shrinking an ext4 volume, from /dev/myvg/mylv mounted at /data. We’ll aim to reduce it by 10 Gigabytes.

1. Check Your Free Space. This is obvious, but you’d be surprised how many people forget. The filesystem must have enough free space within itself to accommodate the new, smaller size.

df -h /data

2. Unmount the Filesystem. As I said, I prefer offline for this. It’s safer.

umount /data

3. Force a Filesystem Check. This is a critical best practice. We want to make sure the filesystem is utterly pristine before we start chopping bits off.

# The -f flag forces the check even if the filesystem looks clean.
sudo e2fsck -f /dev/myvg/mylv

4. Shrink the Filesystem Itself. Here we use the resize2fs command to tell the ext4 filesystem to shrink to its new desired size. Let’s say we want to go down to 30G. Note: we’re telling the filesystem to shrink first.

# Shrink the filesystem to 30G
sudo resize2fs /dev/myvg/mylv 30G

5. Now, and ONLY Now, Shrink the Logical Volume. The filesystem is now physically contained within a 30G space. We can safely tell LVM to reduce the size of the bucket.

# Shrink the LV to 30G. Note the lowercase 'l' for the size.
sudo lvreduce -L 30G /dev/myvg/mylv

6. Remount and Verify. Plug it all back in and make sure everything looks right.

sudo mount /dev/myvg/mylv /data
df -h /data

The “Oh Crap” Scenarios and How to Avoid Them

The biggest pitfall is getting the order wrong. lvreduce before resize2fs is a one-way ticket to data loss. Another classic is trying to shrink the filesystem to a size smaller than the data you have on it. resize2fs is smart and will stop you, but it’s a heart-stopping error to see.

Also, be wary of the flags. -L-10G means “reduce the size by 10G”. -L 10G means “reduce the size to 10G”. A single space is the difference between a successful operation and a horrifyingly small volume. Always, always double-check your lvreduce command before hitting enter. Better yet, use the -t or --test flag first to see what it would do.

# TEST IT FIRST. This does a dry run.
sudo lvreduce -t -L-10G /dev/myvg/mylv

See? It’s a process that feels a bit tedious because it’s built for safety, not for speed. But when you do it right, and that df -h command shows your newly shrunken volume, safe and sound, you’ll feel a satisfaction that only comes from doing a dangerous thing correctly. Now go forth and shrink responsibly. Just not on XFS. Seriously. Don’t.