$ guides / lvm / lvm-insufficient-free-extents ▌

Operations Guides

LVM Insufficient free extents: the volume group is out of space

You ran lvcreate, lvextend, or lvresize and got one of these:

Insufficient free extents
Insufficient free space: 12800 extents needed, but only 0 available

Both messages mean the same thing: the volume group has no unallocated physical extents left for the allocation you requested. Every physical extent in the VG is already assigned to some logical volume, and the operation fails outright.

This is a cliff-edge failure, not a gradual one. A VG at 99% allocated works exactly like a VG at 50% allocated. At 100%, every allocation operation fails immediately: LV creation, LV extension, snapshot creation, and thin pool auto-extend. Existing LVs keep serving I/O, so applications look fine until the moment something tries to grow.

The fix paths are short and well-defined: add capacity to the VG (a new PV, or grow an existing one), or free extents inside it. But if a thin pool or a nearly full filesystem was counting on that extension, the clock is already running.

What this means

LVM divides each physical volume into fixed-size physical extents (PEs), 4 MiB by default. A volume group pools those PEs into one allocatable namespace. When you create or extend an LV, LVM needs enough free PEs to satisfy the request. When vg_free_count is zero, or lower than what you requested, the command fails with the error above.

Three operations depend on those free extents, and all three break at the same time:

LV extension - the direct failure. lvextend and lvresize cannot grow any LV.
Thin pool auto-extend - if dmeventd is configured to grow a thin pool when it crosses a threshold, the extension attempt fires and fails because the VG is empty. The pool then fills to 100%, and writes to every thin LV in it queue under the default queue_if_no_space behavior — the kernel holds them for up to 60 seconds (the dm-thin no_space_timeout module parameter, default 60) and then errors the pool into error_if_no_space mode, failing the queued writes.
Snapshot creation - traditional COW snapshots and thin snapshots both need VG capacity. A backup job that creates a snapshot before reading will start failing here.

One distinction matters before you touch anything: this error is about the VG, not the filesystem. A filesystem on an LV can be 100% full while the VG still has free extents (fix: lvextend -r). The reverse is this article: the filesystem may have room, but the VG cannot allocate anything new. Check both layers, because the remediation is different.

flowchart TD
  A[lvextend or lvcreate fails
Insufficient free extents] --> B{vgs shows
free extents?}
  B -->|0 free| C[VG exhausted]
  B -->|some free, still failing| D{Free space uneven
across PVs?}
  D -->|yes| E[Striped or contiguous LV
cannot allocate]
  D -->|no| F[One-extent rounding:
use -l +100%FREE]
  C --> G{Underlying disk
recently enlarged?}
  G -->|yes| H[pvresize, then retry]
  G -->|no| I{Spare device or
removable LV?}
  I -->|new device| J[pvcreate + vgextend]
  I -->|removable LV| K[lvremove unused LV
or old snapshot]
  I -->|neither| L[Reduce request size
or add storage first]

Common causes

Cause	What it looks like	First thing to check
VG genuinely exhausted	`vgs` shows 0 free extents, 100% allocated	`vgs -o vg_name,vg_size,vg_free,vg_free_count`
Disk enlarged but PV not resized	Cloud or hypervisor disk was grown, but `pvs` still shows the old size	Compare `lsblk` device size against `pvs` PV size
Free space on the wrong PV	VG has free extents but they sit on one PV; a striped LV cannot place all stripes	`pvs -o pv_name,vg_name,pv_size,pv_free`
Rounding discrepancy	You requested the human-readable size shown as free, but the actual extent count is one short	Use `--extents` or `-l +100%FREE` instead of `-L`
Snapshots or forgotten LVs holding extents	Old backup snapshots or orphaned LVs consume a large share of the VG	`lvs -o lv_name,vg_name,lv_size,snap_percent,origin`
Thin pool auto-extend consumed the VG	dmeventd kept extending the pool until the VG ran dry	`lvs -o lv_name,data_percent,lv_size` on the pool LV

Quick checks

All of these are read-only.

# Exact free extent count, not rounded human-readable output
vgs -o vg_name,vg_size,vg_free,vg_free_count,vg_extent_count

# Per-PV free distribution (striped LVs care about this)
pvs -o pv_name,vg_name,pv_size,pv_free,pv_attr

# What is consuming the VG: all LVs with sizes
lvs -o lv_name,vg_name,lv_size,lv_attr,snap_percent,origin

# Thin pool pressure, if you use thin provisioning
lvs -o lv_name,vg_name,data_percent,metadata_percent

# Device size vs PV size (catches forgotten pvresize)
lsblk -o NAME,SIZE,TYPE
pvs -o pv_name,pv_size

# Whether dmeventd is watching thin pools at all
systemctl is-active lvm2-monitor.service
pgrep -x dmeventd

Note that pvs, vgs, and lvs take VG metadata locks and read from disk. On a system already in I/O distress (for example a full thin pool hanging writes), these commands can hang. During an active incident, dmsetup status reads from kernel memory with no LVM locks and no disk I/O. It is the safer tool when everything else stalls.

How to diagnose it

Confirm the VG is actually out of extents. Run vgs -o vg_name,vg_free,vg_free_count. If vg_free_count is 0, the VG is fully allocated. Do not trust the human-readable vg_free value alone: LVM rounds for display, and “0.00g” can hide remaining extents smaller than the rounding step.
Check whether the failure is distribution, not total capacity. If vgs shows free space but the command still fails, look at pvs per-PV free. A striped LV needs free extents on every PV it stripes across. A VG showing 30% free, all on one PV, cannot extend a stripe set that spans three.
Check for the forgotten pvresize. If the underlying disk, partition, SAN LUN, or cloud volume was recently enlarged, the PV still reports its old size until you run pvresize. Compare lsblk device size against pvs PV size. A mismatch is your fix, and it is the cheapest one available.
Account for every allocated extent. lvs -o lv_name,lv_size,origin,snap_percent shows what owns the space. Look for old backup snapshots nobody removed and LVs that no longer back anything.
If thin provisioning is in play, check the pool separately. lvs -o lv_name,data_percent,metadata_percent on the pool. A VG at 100% with a thin pool at 90%+ is the urgent version of this problem: auto-extend cannot fire, and the pool is heading for a write freeze.
Decide the fix class. Add capacity (new PV or pvresize), free capacity (remove LVs or snapshots), or shrink the request (smaller extension, -l +100%FREE).

Metrics and signals to monitor

Signal	Why it matters	Warning sign
VG free extents / percent free	The headroom this error consumes; cliff-edge at 0	Below 10% free, or a sustained downward trend
Per-PV free distribution	Striped and contiguous allocations fail even with aggregate free space	One PV at 100% while others have space
Thin pool data_percent	A full VG removes the pool’s escape hatch	Above 85% with no VG free space
Thin pool metadata_percent	Separate exhaustion domain, harder to recover	Above 75%
Snapshot snap_percent and age	Snapshots silently consume VG extents from origin writes	Any snapshot over 24 hours old, or snap_percent above 80%
dmeventd running + auto-extend config	The safety net only works if it exists and has VG room to extend into	dmeventd down, or threshold at 100 (disabled)

Fixes

Add capacity: extend an existing PV

If the underlying device was already grown (larger cloud volume, expanded SAN LUN, resized partition), the PV just does not know yet:

# Grow the PV to fill its device
pvresize /dev/sdb

# Confirm free space appeared
vgs -o vg_name,vg_free,vg_free_count

This is online and non-disruptive. Then retry your original lvextend or lvcreate.

Add capacity: attach a new PV

When no existing device can grow, add one:

# Stamp a new PV and add it to the VG
pvcreate /dev/sdc
vgextend myvg /dev/sdc

# Confirm
vgs -o vg_name,vg_free,vg_free_count

Both commands are online. The tradeoff: new extents land only on the new PV. Striped LVs that span existing PVs will not automatically rebalance onto it, and a linear LV extended now becomes dependent on the new device. If that device later disappears, the extended LV goes with it. Verify the new device has the redundancy profile you expect before making production LVs depend on it.

Free extents: remove what you no longer need

# DESTRUCTIVE: permanently deletes the LV or snapshot and its data
lvremove myvg/old_backup_snap
lvremove myvg/unused_lv

Removing a snapshot frees its exception store immediately. Removing an LV frees all its extents. Both are irreversible; confirm the target is genuinely unused (no mount, no open file descriptors, no dependent VM or container) before running. For thin LVs, removal also returns blocks to the pool, which can relieve pool pressure at the same time.

Shrink the request

If you only need whatever is left, skip the size arithmetic entirely:

# Take all remaining free extents
lvextend -l +100%FREE /dev/myvg/mylv

# Or create with all of them
lvcreate --extents 100%FREE --name mylv myvg

This also sidesteps the classic one-extent-off failure, where you request the rounded size vgdisplay shows and metadata overhead leaves you one extent short.

If a thin pool is already at 100%

The priority order changes. Extend the pool LV itself the moment any free extents exist:

# After freeing or adding VG space, grow the pool LV (not individual thin LVs)
lvextend -L +20G myvg/thinpool

Until then, writes to thin LVs are queuing or failing. If nothing can be freed and no device can be added, your remaining options are fstrim on thin LV filesystems (reclaims pool blocks only if discard support exists through the whole stack) and deleting thin snapshots to return blocks.

Prevention

Alert on VG free space, not just filesystem usage. df cannot see this failure coming. Ticket below 10% free, start planning below 20%. The VG, the thin pool, and the filesystem are three independent capacity dimensions.
Track the trend, not the snapshot. A VG at 80% that has not moved in months is different from one that consumed 20% last week. Estimate runway from consumption rate.
Verify auto-extend actually works. thin_pool_autoextend_threshold defaults to 100 in /etc/lvm/lvm.conf, which means disabled. If you set it to 80, also verify dmeventd is running and that the VG has room for at least two extension cycles. Auto-extend with a full VG fails silently.
Keep snapshot lifetimes short. Alert on any snapshot older than 24 hours on a busy origin. Zombie snapshots are the most common way VGs fill without anyone noticing.
Run pvresize as part of every disk-growth runbook. Growing the device without resizing the PV is the single most common cause of this error appearing when it should not.
Keep an emergency buffer. Enough free extents for one thin pool extension plus one emergency snapshot, minimum.

How Netdata helps

VG free space per volume group, tracked over time, so the cliff edge shows up as a trend line days before lvextend fails.
Thin pool data and metadata percentages side by side with VG free space, which is the correlation that matters here: a pool at 90% is a ticket, a pool at 90% with a VG at 0 free is a page.
Snapshot usage and age, catching zombie snapshots that quietly eat the extents you thought you had.
Device and dm-level I/O metrics, so when a full VG does cascade into a frozen thin pool, you can see the write stall and D-state buildup rather than a vague “server is slow” report.
Filesystem and LVM capacity in the same view, closing the gap where teams alert on df but never see the VG run dry underneath a half-full filesystem.