Linux · critical · Storage, filesystems & NFS

LVM thin pool full — volumes go read-only or the machine hangs

The pool has run out of real blocks to hand out. The volumes inside it still believe they have space, which is what makes this so abrupt.

What you see

Applications report write errors on a filesystem that shows free space. The machine may hang entirely. The kernel log carries device-mapper thin messages.

What is actually wrong

Thin volumes are over-provisioned by design. Snapshots that were never removed, or growth that outpaced the pool, exhaust the physical extents behind them.

Codes and articles

thin pool is now fullData space exhausteddevice-mapper: thinlvs Data%out of data space

Fixes (2)

Extend the pool immediately, then set the thresholds

Root shell25 minutesmedium risknot reversible

The volume group has free space. Do this first — a full thin pool can corrupt what is inside it.

See the exact state. The Data% and Meta% columns are what matter.
Shell
```
sudo lvs -a -o+seg_monitorsudo vgs
```
Metadata can exhaust before data does, and it produces the same symptom. Extending only the data half of a pool whose metadata is full does nothing at all.
Extend the data portion.
Shell
```
sudo lvextend -L +50G vg0/thinpool
```
Extend the metadata separately if Meta% is high.
Shell
```
sudo lvextend --poolmetadatasize +1G vg0/thinpool
```

Turn on automatic extension so this is caught before it is critical.

Shell

sudo sed -i 's/^\s*thin_pool_autoextend_threshold.*/\tthin_pool_autoextend_threshold = 80/; s/^\s*thin_pool_autoextend_percent.*/\tthin_pool_autoextend_percent = 20/' /etc/lvm/lvm.confsudo systemctl restart lvm2-monitor

Check the filesystems inside are still consistent after a full-pool event.
Shell
```
sudo xfs_repair -n /dev/vg0/data || sudo fsck -n /dev/vg0/data
```

Confirm it workedlvs shows Data% and Meta% well below 100 and the volumes are writable.

Shell

sudo lvs -a -o+seg_monitor

If you need to undo itAn extended logical volume cannot be shrunk safely with data on it; the extension is one-way in practice.

Reclaim space when there is none left to add

Root shell40 minuteshigh risknot reversible

The volume group is also full.

List the snapshots — these are almost always where the space has gone.
Shell
```
sudo lvs -a -o lv_name,lv_attr,origin,data_percent,lv_size | grep -E '^\s+\S+\s+s'
```
A snapshot taken for a backup and never removed keeps every block the origin has changed since. A month of those will consume a pool on its own, and removing them is instant relief.
Remove the snapshots you no longer need, oldest first.
Shell
```
sudo lvremove vg0/snap-2026-05-01
```
Enable discard so deletions inside the guest filesystem return blocks to the pool.
Shell
```
sudo lvchange --discards passdown vg0/thinpoolsudo fstrim -av
```
Without discard passdown, deleting a file inside a thin volume frees nothing in the pool. This is why a pool keeps filling on a filesystem that has plenty of free space.

Add a physical volume to the group if there is a spare disk.

Shell

sudo pvcreate /dev/sdcsudo vgextend vg0 /dev/sdcsudo lvextend -l +100%FREE vg0/thinpool

Set up monitoring on Data% — this fault has no gentle warning stage.

Confirm it workedData% has fallen and fstrim reports blocks returned.

Shell

sudo lvs -a; sudo fstrim -av

If you need to undo itRemoved snapshots cannot be recovered.

Related faults

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.