Stop LVM thin-provisioning from biting you when the pool runs dry
By Saket Jain Published Linux/Unix
Stop LVM thin-provisioning from biting you when the pool runs dry
Technical Briefing | 8/25/2026
You set up a thin-provisioned LVM pool because you wanted to oversubscribe your storage. It works great for months. Then one Tuesday at 3 AM, the pool hits capacity, the kernel pauses your I/O, and every database on the node goes into an uninterruptible sleep. This bit me early in my career, and the recovery is a nightmare of partial writes and stuck mount points.
Why the kernel just stops everything
When a thin pool exhausts its physical blocks, LVM has no choice but to stall the requests. It doesn’t throw a polite error; it waits for more space to magically appear. If your applications are expecting low latency, this lockup effectively kills them. You cannot just delete a file to free up space because the filesystem is locked by the block layer, creating a classic chicken-and-egg problem.
lvs -a -o lv_name,attr,pool_lv,data% /dev/vg_data/thin_pool
- Monitor the data percent field aggressively because once you hit 95 percent, the threshold for recovery becomes tiny
- Set up low-watermark alerts that trigger when the metadata or data pools cross 80 percent utilization
- Avoid snapshots that stay around for weeks as they hold onto blocks that might otherwise be discarded
Setting up a safety net
You should configure the thin_pool_autoextend_threshold in lvm.conf. Most defaults are too generous or disabled entirely. By setting this to something like 70 and defining a percentage to add, you get a buffer that keeps the kernel from hitting that fatal wall. Just make sure your underlying Physical Volume has enough free PEs to actually accommodate the extension, otherwise the auto-extend will silently fail and you are right back where you started.
Keep an eye on the metadata usage specifically. Unlike data blocks, if your metadata sub-pool fills up, the thin pool will go read-only, which is almost always catastrophic for running services. It is worth spending the extra overhead to mirror your metadata sub-volumes; losing those is basically losing the entire filesystem structure.
