LVM has free space but striped or mirrored allocation still fails

vgs shows the volume group 30% free. lvcreate for a striped or mirrored logical volume, or lvextend on an existing one, fails anyway:

Insufficient suitable allocatable extents for logical volume

The VG has headroom and the operation needs less than that headroom. Both facts are true at once, and that is the trap: vg_free is an aggregate across every physical volume in the group, but striped and mirrored allocations are not aggregate operations. They are per-PV placement problems. LVM must find extents on multiple distinct PVs at the same time, and if your free space is piled onto one PV, the allocation has nowhere legal to go.

The VG health signals all look fine. Nothing is degraded, nothing is missing. The only symptom is that a specific class of operation refuses to proceed, and the error message does not tell you why.

What this means

A striped LV with N stripes needs extents on N distinct PVs for every stripe unit it grows by. Under the default normal allocation policy, LVM will not place an extent for one stripe on the same PV as an extent already allocated to a parallel stripe of the same LV. That rule is what gives striping its parallelism, and mirroring its redundancy. It is also what makes allocation fail when free extents exist but are not spread across enough PVs.

The same logic applies to redundancy. A mirrored LV needs each leg on a different PV, otherwise one disk failure takes out both copies and the mirror is decoration. Legacy mirror type LVs additionally need a PV for the mirror log by default (--mirrorlog disk), so a two-leg mirror needs three PVs with free space. The modern raid1 type does not need a separate log PV, but each image still needs its own PV.

So the real capacity question for striped or mirrored LVs is not “how much free space does the VG have?” It is “how is the free space distributed across PVs, and how many PVs does this segment type need?” A VG showing 30% free with all of it on one PV cannot satisfy a striped allocation, and operations fail despite apparent headroom.

Common causes

Quick checks

All read-only and safe to run during an incident. Note that pvs, vgs, and lvs take VG locks and scan devices; on a stressed system they can hang. If they do, fall back to dmsetup, which reads kernel state directly.

# The single most important check: per-PV free distribution
pvs -o pv_name,vg_name,pv_size,pv_free

# Aggregate VG view, for contrast
vgs -o vg_name,vg_size,vg_free,vg_free_count,pv_count

# Check PV allocatable state (a PV can show free space but be disabled)
pvs -o pv_name,pv_allocatable

# See exactly which PVs back each segment of the LV you are extending
lvs -o lv_name,vg_name,seg_type,stripes,devices

# Segment-to-PV mapping across the VG
pvs --segments -o pv_name,lv_name,seg_start_pe,seg_size_pe

# Check the LV's allocation policy (attr position 3) and segment type
lvs -o lv_name,lv_attr,seg_monitor

# Any interrupted pvmove leaving temporary mirror state
pvs --noheadings -o pv_name,move_pv

What to look for:

• One PV holding all the free space. If pvs shows /dev/sdc: 200 GiB free and every other PV at zero, a 2-stripe LV cannot be allocated at all, and a mirror cannot place two legs.
• Fewer PVs with free space than the stripe count. A 3-stripe LV needs 3 PVs with usable free extents.
• lv_attr position 3. The allocation policy character: n normal, c contiguous, l cling, a anywhere. Cling or contiguous on a striped LV is a red flag for extend failures.

How to diagnose it

1. Confirm the failure class. Read the full error. “Insufficient suitable allocatable extents” means placement constraints could not be satisfied. “Insufficient free space: X extents needed, but only Y available” means raw extent count is short. The first points at distribution; the second at genuine capacity. If the message includes “contiguous”, the LV requires adjacent extents on a single PV, which is the strictest policy of all.

2. Map free space per PV. Run pvs -o pv_name,pv_free. Ignore vg_free entirely for this diagnosis. Count how many PVs have nonzero free space and how much each holds.

3. Determine what the segment type needs. For a striped LV, the stripe count (lvs -o stripes) is the minimum number of distinct PVs required for each allocation step. For a mirrored or raid1 LV, the leg/image count is the minimum. For a legacy mirror type LV with a disk log, add one more PV for the log.

4. Compare need against distribution. If stripes = 3 but only 2 PVs have free extents, the diagnosis is complete. If enough PVs have free space but the operation still fails, check the allocation policy next.

5. Check the allocation policy. Look at lv_attr position 3. A cling policy tries to place new extents on the same PV as existing extents for that LV, which directly conflicts with striping. A contiguous policy requires adjacent extents, which striped segments cannot satisfy across PVs.

6. Check for disabled PVs. A PV with pv_allocatable set to no still reports its free space in pvs but contributes nothing to allocation. This quietly reduces your effective PV count.

7. If the failure was during pvmove, treat it as the same problem. Moving a striped LV makes pvmove build a temporary mirror that inherits the striping constraints, so the same distinct-PV requirement applies to the migration target.

flowchart TD
  A[lvcreate or lvextend fails] --> B{Read the error}
  B -->|Insufficient free space| C[Genuine capacity shortage - add a PV]
  B -->|Insufficient suitable allocatable extents| D[pvs -o pv_name,pv_free]
  D --> E{Free extents on enough distinct PVs?}
  E -->|No| F[Free space concentrated on too few PVs]
  F --> G[Add PV or rebalance with pvmove]
  E -->|Yes| H{Check allocation policy}
  H -->|cling or contiguous| I[Retry with --alloc normal]
  H -->|normal| J[Check pv_allocatable and mirror log PV count]

Metrics and signals to monitor

If you run striped or mirrored LVs in production, per-PV free space distribution is not optional monitoring. The failure mode this article covers is invisible until an operation fails, and the only leading indicator is the distribution itself.

Fixes

Add a PV to the VG

The clean fix when you do not have enough distinct PVs. Provision a new device, pvcreate it, vgextend the VG onto it, then retry the allocation. This preserves striping and redundancy semantics. The tradeoff is obvious: you need another disk, LUN, or partition, and for striping to actually deliver parallelism, the new PV should be physically independent of the existing ones. Two PVs on the same controller or shelf give you allocation success without real isolation.

Rebalance with pvmove

If the VG already has multiple PVs but one is full and another is empty, pvmove extents off the full PV to even out the distribution, then retry. Two caveats. First, pvmove creates a temporary internal mirror, so moving a striped LV can hit the same distinct-PV constraint you are trying to fix. Second, never kill a pvmove with kill -9; if it is interrupted, complete it or run pvmove --abort. A crashed pvmove leaves the LV in a temporary mirror configuration that looks like an unrelated mirror problem in lvs output. The distinguishing signal is p (pvmove) in lv_attr position 1.

Extend a striped LV as a new linear segment

When you cannot add a PV right now but must grow the LV, extend without adding stripes:

# Extend a striped LV with a new linear segment on one PV
lvextend -i1 -l+100%FREE vg/lv

This appends a new linear segment to the striped segments. The LV grows and the workload continues, but new I/O to the extension gets no striping benefit and the LV becomes a mixed-layout device. Treat it as a bridge to a proper fix (add a PV, then consider migrating), not as a destination.

Override the allocation policy for the operation

If a cling or contiguous policy is the blocker, override it for this command:

# Extend with the normal policy instead of the inherited one
lvextend --alloc normal -l+100%FREE vg/lv

You can also change the VG default with vgchange --alloc normal <vg>. Check why the policy was set before changing it; someone may have set contiguous deliberately for a specific workload.

The --alloc anywhere trap

--alloc anywhere forces the allocation to succeed by relaxing the distinct-PV rule. For a mirrored or RAID LV this can place multiple legs on the same PV, silently destroying the redundancy you created the LV for. One disk failure then takes out every leg at once. For a striped LV it can collapse stripes onto one PV, removing the parallelism. Do not use it as a quiet way to make the error go away. If you ever use it deliberately, immediately verify leg placement with lvs -o lv_name,devices and plan a rebalance.

Mirror log considerations for legacy mirror LVs

If you are creating a legacy --type mirror LV, the disk-based mirror log needs its own PV by default. A two-PV VG cannot host a two-leg mirror with a disk log. Options: add a third PV, or use --mirrorlog core to keep the log in memory. The core log tradeoff is a full resync after every reboot or crash, which on a large LV means hours of degraded redundancy and heavy resync I/O competing with production. Prefer --type raid1, which keeps the log integrated per-image and needs no extra PV.

Prevention

• Monitor per-PV free distribution, not just vg_free. Alert when the minimum free space across PVs in a VG approaches zero while the aggregate looks fine. That skew is the leading indicator for this exact failure.
• Plan capacity per PV for striped and mirrored LVs. A 4-stripe LV effectively requires each participating PV to have at least LV_size / stripes free. Capacity planning on vg_free alone will overpromise.
• Size PV additions to match stripe layouts. When you grow a VG that hosts striped LVs, add PVs in multiples of the stripe count so allocation stays balanced.
• Audit allocation policies. Striped or mirrored LVs carrying a cling or contiguous policy are extend failures waiting to happen. Review lv_attr position 3 periodically.
• Prefer raid1 over legacy mirror on modern systems. It removes the third-PV log requirement and the core-log resync tradeoff.
• Keep PVs physically independent. Redundancy across PVs on the same controller or shelf is allocation success without fault isolation. LVM metadata gives you no visibility into physical topology; document it yourself.

How Netdata helps

• Per-device visibility. Netdata collects block-device I/O, latency, and utilization metrics per device out of the box, and filesystem capacity per mount. Raw PV free space is LVM metadata rather than device or filesystem state, so trend it alongside Netdata via a scripted collector or cron-exported pvs output if you want the distribution skew visible as a trend rather than a point-in-time snapshot.
• Aggregate versus per-device correlation. The gap between healthy-looking pool totals and exhausted individual devices is exactly the class of problem per-second, per-device dashboards surface: one device pinned at 100% while the average sits at 70%.
• I/O pressure during remediation. If you fix this with pvmove, Netdata’s disk I/O and latency charts on the source and target PVs show the migration’s cost against production traffic in real time, so you can throttle or schedule it.
• Device-layer corroboration. When allocation failures coincide with a PV going missing or flapping (a different root cause with similar symptoms), disk health and I/O error signals distinguish device loss from simple distribution skew.
• Alerting on the leading indicator. Alerting on per-device saturation rather than pool aggregates converts this from a failed-change-at-midnight incident into a capacity ticket during business hours.

Related guides

• How LVM actually works in production: a mental model for operators
• LVM Insufficient free extents: the volume group is out of space
• LVM monitoring checklist: the signals every production volume manager needs
• LVM monitoring maturity model: from survival to expert