LVM Thin Provisioning: Over-Committing Safely

lvm-guide built a normal logical volume: lvcreate -L 50G carves 50 GB out of the pool the moment you run it, whether you ever write a byte or not. The space is spent on day one — the same day-one guess raw partitions forced on you, just one layer up.

Thin provisioning breaks that too. A thin logical volume is given a virtual size when you create it, but it consumes real blocks from its pool only as data is actually written. Create a 200 GB thin LV on a 100 GB pool and nothing is wrong: it reports 200 GB, and the pool hands out real blocks as writes arrive. The consequence is the headline: the virtual sizes of all the thin LVs in a pool can legitimately add up to more than the physical space behind them. That is over-commitment, and it is a feature, not an accident.

The mechanism is worth stating precisely because the whole lesson hangs on it. The lvmthin(7) manual puts it plainly: "blocks in a thin provisioned LV are allocated as they are written… a thin provisioned LV is given a virtual size, and can then be much larger than physically available storage." So a thin LV is a promise to allocate later, backed by a shared reservoir of real blocks called the thin pool. As long as the reservoir has blocks left, every promise is honoured. The engineering — and the risk — is entirely about what happens when it doesn't.

A thin pool is not a single object. It is two logical volumes doing different jobs: a large data LV that actually holds the blocks written to every thin volume, and a small metadata LV that records which block belongs to which thin LV (and to which snapshot). You can let LVM build both in one command, or fuse two LVs you made yourself — the second form is worth seeing once, because it is what the one-shot is doing for you.

lvm-guide taught you to read lvs per layer. Thin pools add two columns you must read together, because they fail independently. The Attr string tells you what a row is: a leading `t` marks a thin pool, a leading `V` marks a thin volume. Then Data% is how full the pool's data reservoir is, and Meta% is how full its metadata is — and a pool can be half-empty on data and completely out of metadata at the same time. Metadata exhaustion is the failure nobody sees coming, because they were watching the big number.

Here is the fact that makes over-commit survivable instead of reckless. When a thin pool's data space is exhausted, reads keep working — the blocks already written are still there and still mapped. It is writes that fail, because there is no free block to allocate. lvmthin(7): "the errorwhenfull setting applies only to writes; reading thin LVs can continue even when data space is exhausted." Whether a write fails loudly (an immediate I/O error) or hangs waiting for space is a per-pool setting, --errorwhenfull y|n, chosen when the pool is created or changed.

You do not manage a thin pool by hoping. LVM ships a monitoring daemon, dmeventd, that watches every activated pool and acts before full. Per lvmthin(7), it emits syslog warnings at 80%, 85%, 90% and 95% pool usage, and — if configured — auto-extends the pool from the VG's free space so it never reaches 100%. Two lvm.conf settings govern it: thin_pool_autoextend_threshold (the percent-full that triggers an extension; 100 disables auto-extend, and the minimum useful value is 50) and thin_pool_autoextend_percent (how much to add each time, as a percentage of current size).

Thin pools change what a snapshot costs. A classic copy-on-write snapshot (from lvm-guide) reserves a fixed chunk of space up front and is dropped if the origin changes more than that reservation — and a snapshot of a snapshot compounds the overhead. A thin snapshot is just another thin volume in the same pool that starts out sharing all of the origin's blocks. Nothing is copied at creation; blocks diverge only when either side is written. lvmthin(7): snapshots of thin LVs "share common data blocks with their origin," snapshots may be taken of snapshots, and "there is no limit to or degradation from sequences of snapshots."

The write commands need a real pool (that's the paired lab). But the reads are the first thirty seconds of every thin-pool task you'll ever do, and they run anywhere. Walk them for real: the point is to build the reflex of reading Data% and Meta% together before you trust — or touch — a pool. On a box with no LVM these print empty and still exit cleanly; the muscle memory is the goal.