Stop Letting df Lie About Your LVM Thin Pool Space

Technical Briefing | 10/26/2026

You fire up a new VM, give it a nice fat 500GB disk on your LVM thin pool, df inside the guest looks happy, everything’s green. A month later, your applications start screaming about “disk full,” but wait, df -h on the host says the logical volume is barely touched. What the hell happened? That’s the sound of an LVM thin pool running dry, and df just sits there, smugly reporting a fiction. This bit me hard back when I first moved systems to thin provisioning; we had plenty of reported space, then suddenly, kaput.

Understanding the “Thin” in Thin Provisioning

When you create an LVM thin logical volume, you’re not actually allocating all that space upfront. You’re telling LVM, “Hey, this VM thinks it has 500GB, but only give it blocks from the underlying thin pool when it actually writes data.” It’s brilliant for over-provisioning and maximizing storage efficiency. But here’s the kicker: df inside the guest, or even vgs/lvs without the right flags on the host, only shows you that logical size. It completely ignores the physical consumption of the shared thin pool that all your thinly provisioned volumes are drawing from.

Your vgdisplay might tell you a volume group has terabytes free, but that’s often just the physical extent free outside of any thin pools. Inside a thin pool, space is allocated in chunks, along with essential metadata to track which logical block belongs to which virtual disk. You can easily have an lvdisplay output that shows 20% usage on a specific logical volume, while the entire thin pool is at 95% capacity, shared across a dozen other logical volumes. That’s a ticking time bomb. I’ve seen this bite so many people in prod when VMs start abruptly failing writes, not because their own virtual disk is full, but because the shared physical pool underneath is choked.

Get the Real Story: Peeking Into Your Thin Pool’s Soul

vgs --units g
lvs -o+data_percent,metadata_percent,pool_lv -a --units g

The `vgs` command gives you a quick overview of your volume groups. You’ll want to pay close attention to the `VFree` column. But for the real lowdown on thin pools, `lvs` is your friend, but you need to ask it the right questions. Those `data_percent` and `metadata_percent` columns are what you’re after. They tell you the actual physical utilization of your thin pool’s data and metadata areas, respectively. And don’t ignore the `metadata_percent` – if that fills up, you’re just as dead in the water as if the data area fills. I’ve seen metadata fill up even on relatively “empty” pools due to heavy snapshotting or lots of small, fragmented writes, which is a nasty surprise.

What to Do When the Pool is Gasping for Air

• **Expand the thin pool:** If you have free physical extents in the volume group, you can extend the thin pool’s size with `lvextend`. This is the easiest fix if you have headroom and it’s the right solution for planned growth.
• **Migrate or remove data:** If expanding isn’t an option, you’ll need to free up space. This could mean deleting unused logical volumes, or migrating data off existing ones to another storage location. Sometimes, a full-on data prune inside a guest can make a difference.
• **Monitor aggressively:** Set up alerts for `data_percent` and `metadata_percent` thresholds. Don’t wait for your applications to scream; catch it at 80% or 85% so you have time to react, not just panic.
• **Understand block reclamation:** When you delete files *inside* a guest, the thin pool often doesn’t immediately reclaim those blocks. You might need to use `fstrim` or similar tools inside the guest to hint to the storage layer that blocks are free. Otherwise, that space just sits there, still marked as used, which can be confusing after a cleanup operation.

This isn’t just about avoiding an outage, it’s about predictable capacity planning. You don’t want to find yourself scrambling at 2 AM trying to figure out why a ‘mostly empty’ filesystem just died. Get your monitoring in place, understand the real numbers, and you’ll be able to proactively manage your storage, not react to its sudden death. And for god’s sake, put those `data_percent` metrics on your dashboards.