LVM thin provisioning: allocate storage on demand

LVM thin provisioning allocates disk space as data is written, not when the volume is created. You can therefore carve volumes whose declared sizes add up to more than the physical space actually available, the well-known overcommit. This guide shows how to create a thin pool, provision volumes in it, watch how full it is with Data%, and set up automatic extension to avoid exhaustion. For intermediate Linux administrators, on Debian/Ubuntu and RHEL/AlmaLinux. All outputs come from a real test on AlmaLinux 10 (LVM 2.03.36).

What you will learn

• Tell a thin pool from a thin volume
• Create a pool and carve overcommitted volumes in it with lvcreate --thin
• Read Data% to follow actual consumption
• Set up automatic extension (thin_pool_autoextend_threshold)
• Understand the danger of a full pool and prevent it

Prerequisites

A working LVM stack (see the LVM guide) and the thin tools installed. On RHEL and AlmaLinux 10, lvm2 already pulls in device-mapper-persistent-data; on Debian 13, thin-provisioning-tools is only a recommendation of lvm2, missing from a minimal install:

Debian/Ubuntu

sudo apt install thin-provisioning-tools lvm2

RHEL/AlmaLinux

sudo dnf install device-mapper-persistent-data lvm2

Without these tools, LVM still creates the pool, but it can no longer check its metadata: at every activation, it prints "WARNING: Check is skipped, please install recommended missing binary /usr/sbin/thin_check!". A pool whose metadata is never checked is a pool whose corruption you will discover too late. The kernel must also load the dm-thin-pool module, present by default on all recent distributions.

Thin pool and thin volume: the model

Thin provisioning adds a level of indirection. Instead of carving a volume directly from the Volume Group, you first create a thin pool (a reservoir of real space), then provision thin volumes inside that pool. Each thin volume announces a size (its virtual size), but only consumes the pool's physical space when data is written to it.

The direct consequence is overcommit: the sum of the volumes' virtual sizes can exceed the pool's real size, exactly like a bank lends more money than it holds in cash, betting that not all customers will withdraw everything at the same time.

Create a thin pool and a thin volume

You create the pool with --type thin-pool, then a volume with --thin, giving its virtual size through -V:

1. Create the thin pool (1.5 GiB of real space here) in a VG named vg_data:

   sudo lvcreate --type thin-pool -L 1.5G -n pool0 vg_data

     Thin pool volume with chunk size 64.00 KiB can address at most <15.88 TiB of data.
     Logical volume "pool0" created.

2. Provision a thin volume of 5 virtual GiB in this 1.5 GiB pool:

   sudo lvcreate --thin -V 5G -n thinvol vg_data/pool0

     WARNING: Sum of all thin volume sizes (5.00 GiB) exceeds the size of
     thin pool vg_data/pool0 and the size of whole volume group (<2.00 GiB).
     WARNING: You have not turned on protection against thin pools running out of space.
     WARNING: Set activation/thin_pool_autoextend_threshold below 100 to trigger
     automatic extension of thin pools before they get full.
     Logical volume "thinvol" created.

LVM explicitly warns about the overcommit and the lack of protection, and even names the setting that enables it. These warnings are not errors: they remind you that monitoring how full the pool gets is now your responsibility.

Overcommit in action

This is where thin provisioning makes sense. The Data% column shows the space actually consumed in the pool, regardless of the declared virtual sizes. Right after creation, everything is at zero:

sudo lvs -o lv_name,lv_size,pool_lv,data_percent vg_data

  LV      LSize Pool  Data%
  pool0   1.50g       0.00
  thinvol 5.00g pool0 0.00

thinvol shows 5 GiB while the pool only holds 1.5, and yet nothing is consumed. Let's write 500 MiB of real data to the volume, then look again:

sudo mkfs.xfs /dev/vg_data/thinvol
sudo mount /dev/vg_data/thinvol /mnt/data
sudo dd if=/dev/zero of=/mnt/data/bigfile bs=1M count=500
sudo lvs -o lv_name,lv_size,data_percent vg_data

  LV      LSize Data%
  pool0   1.50g 39.12
  thinvol 5.00g 11.74

The pool is now 39.12% full (the 500 MiB written, plus the XFS structures), and the thin volume 11.74% of its 5 virtual GiB. Only the space actually written is consumed: that is the whole point of thin provisioning.

The danger: a pool that fills up

An overcommitted thin pool ends up filling if its volumes all grow at the same time. The test pushed it to the limit: 1.5 GiB written to thinvol while the pool only holds 1.5 in total. After one minute, dd fails with "No space left on device", and lvs shows the pool full:

  LV      Attr       Data%  Meta%
  pool0   twi-aotzD- 100.00 25.20
  thinvol Vwi-aotz-- 30.00

The D in the attribute flags a pool out of data space. The kernel log tells the sequence: "switching pool to out-of-data-space (queue IO) mode", then 61 seconds later "(error IO) mode". That delay is the no_space_timeout parameter of the dm_thin_pool module, which is 60 seconds, and lvs -o lv_when_full shows queue, the default behaviour.

A full pool can corrupt your data

When a thin pool's Data% (or Meta%) reaches 100%, the volumes' writes are queued for 60 seconds, then fail. The official documentation warns that running out of space "risks damaging the file system and requires a repair". The nastiest case is metadata exhaustion (Meta%): the pool becomes unusable even if data space remains.

Overcommit is therefore not magic: if all the volumes fill up at the same time, the pool runs out. The rule is simple: watch Data% and Meta%, and grow the pool before reaching the limit.

sudo lvs -o lv_name,attr,data_percent,metadata_percent vg_data

Grow the pool automatically

Rather than watching by hand, you configure LVM to grow the pool by itself before it runs out. Two directives in /etc/lvm/lvm.conf, activation section:

activation {
    thin_pool_autoextend_threshold = 80
    thin_pool_autoextend_percent = 20
}

• thin_pool_autoextend_threshold: the trigger threshold. At 80, the pool grows as soon as it reaches 80% full. The value 100 disables automatic extension (minimum accepted: 50).
• thin_pool_autoextend_percent: the pool grows by this percentage of its size at each trigger.

The extension relies on the dmeventd daemon, which receives kernel notifications and runs lvextend automatically. The pool must still be monitored:

sudo lvchange --monitor y vg_data/pool0
sudo lvs -o +seg_monitor vg_data/pool0   # must show "monitored"

Autoextend needs free space

Automatic extension only works if the Volume Group still has free space (vgs, VFree column). On a full VG, you must first add a disk with vgextend. Thin provisioning does not create space, it defers its allocation.

When to use thin provisioning

Thin provisioning shines when the declared space far exceeds the space used, or when you multiply volumes:

• Many cheap snapshots: thin snapshots share the pool's blocks instead of preallocating a fixed size.
• VM and container disks: you provision generously without tying up the disk. It is exactly what Proxmox VE does with its LVM-thin backend (in French), which supports native snapshots and clones.
• Controlled overallocation: give every service a comfortable volume without buying the total disk in advance.

The trade-off is always the same: monitoring is not optional. An unmonitored thin pool is an outage waiting for its time.

Troubleshooting

Thin provisioning failures show up in lvs and in the kernel log. Watch the pool's attribute (a D flags a full pool), the Data% and Meta% columns, and the device-mapper: thin messages from dmesg.

Symptom	Likely cause	Fix
Required device-mapper target(s) not detected in your kernel	dm-thin-pool module missing	sudo modprobe dm-thin-pool
Check is skipped, please install recommended missing binary /usr/sbin/thin_check!	thin tools missing	install thin-provisioning-tools (Debian) or device-mapper-persistent-data (RHEL)
Writes stuck for a minute, then No space left on device	pool full (Data% or Meta% at 100, D attribute)	grow the pool (lvextend), add a disk to the VG
The pool does not grow by itself	pool not monitored or VG full	lvchange --monitor y, check vgs (VFree)

Swipe to see more

Key points

• Thin provisioning allocates space on write, not on creation.
• A thin pool (real space) holds thin volumes (virtual size), with lvcreate --type thin-pool then lvcreate --thin -V.
• Overcommit allows a sum of virtual sizes larger than the pool; Data% shows the real usage.
• A full pool corrupts data: watch Data% and Meta%.
• Enable automatic extension (thin_pool_autoextend_threshold) and monitoring (lvchange --monitor y).
• Autoextend needs free space in the VG: thin provisioning does not create disk.

Knowledge check

Check that the essentials of this guide are acquired. The questions only cover what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

6 questions

6 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

FAQ: frequently asked questions about LVM thin provisioning

These answers cover the most frequent questions about thin provisioning: overcommit, pool monitoring and its automatic extension.

What is LVM thin provisioning?

What is overcommit in LVM?

What happens if an LVM thin pool is full?

How do you monitor how full an LVM thin pool is?

What is the difference between a thin pool and a thin volume?

×

See in the glossary →