An LVM thin pool created with `lvcreate -L 200G -T vg0/pool` backs thin volumes whose virtual sizes total 800G. What happens to those volumes when the pool's data space — or its metadata space — actually runs out, and how do you keep that from happening?

## What over-provisioning actually promises A thin pool has a real data area (200 GiB here) and a real metadata area. Thin volumes created with `lvcreate -V 400G -T vg0/pool -n app` present a *virtual* size; blocks are allocated from the pool only when written. Summing virtual sizes to 800G against a 200G pool is legitimate and is the point of the feature — but it is a bet that the volumes will not all fill. Usage is visible in two columns: ``` $ lvs -o lv_name,lv_size,data_percent,metadata_percent vg0 LV LSize Data% Meta% pool 200.00g 71.40 18.20 app 400.00g 34.10 ``` `Data%` is the pool's data area consumption; `Meta%` is its metadata area consumption. Both matter, and people watch only the first. ## Data exhaustion When `Data%` reaches 100: - **Reads still work**, and so do overwrites of blocks that are already mapped — no new allocation is needed. - **Any write requiring a new block cannot be satisfied.** That includes all writes to a region never written before, and *every* first write to a block shared with a snapshot, because redirect-on-write must allocate. - The pool's behaviour on that condition is configurable: `lvchange --errorwhenfull y|n vg0/pool`. With errors enabled, I/O fails immediately and loudly. With the default queueing behaviour, I/O is held for a grace period in the hope that space appears, and then fails — which presents as a hang first and errors second, and is often the more confusing symptom on a pager. - Filesystems then do what they do with I/O errors: XFS shuts the filesystem down; ext4 follows its `errors=` mount option, typically remounting read-only. Applications see write failures. Data written into the page cache but never successfully flushed is lost. Because the pool is shared, this hits every thin volume and snapshot in it simultaneously. That is the structural difference from a classic snapshot, where filling the copy-on-write area invalidates exactly one snapshot and leaves the origin alone. ## Metadata exhaustion The metadata area holds the mapping trees. It is small and easy to ignore, and it grows with the *number of mappings*, which is driven by snapshot count, small chunk sizes, and how much the volumes have diverged. If `Meta%` reaches 100, dm-thin puts the pool into read-only mode to protect the metadata it still has. That is not something you resolve by adding data space; recovery generally means deactivating the pool, working on a copy of the metadata with `thin_check` and `thin_repair` from the device-mapper persistent-data tools, and restoring the repaired metadata. Plan the metadata area up front (`lvcreate --poolmetadatasize`, extendable later with `lvextend --poolmetadatasize`) rather than discovering it during an incident. ## Prevention, in the order it pays off 1. **Alert on both numbers.** Export `Data%` and `Meta%` from `lvs` and page below the cliff — 75–80% gives room to act. This is the single highest-value control. 2. **Enable autoextend and make it possible.** `thin_pool_autoextend_threshold` and `thin_pool_autoextend_percent` in `lvm.conf`, with `lvm2-monitor` running so dmeventd can act. Autoextend allocates from the volume group, so the VG must retain free extents. A VG allocated to the last extent silently disables the safety net. 3. **Make discards reach the pool.** Deleting a file does not return blocks by itself. Either mount the filesystem with discard support or run `fstrim` on a schedule, and keep the pool's discard handling at the default that passes them down. Without this, a pool that has churned through data climbs monotonically even though the filesystems look half empty. 4. **Bound snapshot retention.** Every retained snapshot pins the blocks it references, so old snapshots are the usual reason a pool grows while the live data does not. 5. **Govern the over-commit ratio.** 4:1 on a pool nobody watches is reckless; 4:1 on a pool with alerting, autoextend and VG headroom is a considered decision. Write down which one you are running. 6. **Have the emergency runbook.** `lvextend -L +100G vg0/pool` for data, `lvextend --poolmetadatasize +1G vg0/pool` for metadata, plus removing an expendable snapshot to release blocks immediately. Rehearse it, because the situation where you need it is exactly the one where filesystems are already going read-only. ## The interview point Thin provisioning does not create capacity; it defers the moment you must have it, in exchange for a shared failure mode that is worse than the one it replaced. The engineer who has operated it talks about `Meta%`, discards, free extents in the volume group, and the alert threshold. The one who has only read about it talks about how much space it saves.