LVM Thin Provisioning and Thin Snapshots in Practice

Thin provisioning decouples the size a volume claims from the space it consumes: blocks are allocated on write. That makes snapshots nearly free and overprovisioning cheap, but it also means the pool is a shared resource that can fill up underneath every volume that uses it. This guide covers building the pool, using thin snapshots correctly, and monitoring the two numbers that cause outages when ignored.

Create the Pool

vgcreate vg0 /dev/nvme0n1
lvcreate --type thin-pool -L 400G -n thinpool vg0
lvcreate -V 1T --thin-pool vg0/thinpool -n vm-disk0
lvs -o name,size,data_percent,metadata_percent vg0

A thin pool is two hidden volumes behind the scenes: _tdata holds the blocks and _tmeta holds the mapping metadata maintained by the dm_thin_pool kernel module. A virtual size of 1 TB on a 400 GB pool is normal - and exactly why you must watch Data% and Meta%.

Thin Snapshots Done Right

! correct: no size argument - this creates a thin snapshot
lvcreate --snapshot -n vm-disk0-snap1 vg0/vm-disk0
! snapshot of a snapshot is fine
lvcreate --snapshot -n vm-disk0-snap2 vg0/vm-disk0-snap1
! remount as a writable clone
lvconvert --thinpool vg0/thinpool

The one mistake to avoid is passing -L/--size: with a size, LVM creates a classic copy-on-write snapshot with a fixed chunk store that becomes a performance problem as it fills. Thin snapshots share unchanged blocks, so chains of them do not degrade the way stacked COW snapshots do - but they still consume pool space as origin and snapshot diverge.

Keep the Pool From Filling

lvextend --use-policies vg0/thinpool
lvextend -L+100G vg0/thinpool
systemctl status lvm2-monitor

dmeventd's thin plugin watches the pool and can autoextend it with lvextend --use-policies, provided there is free space in the volume group - so keep headroom in the VG, not just the pool. Decide the pool-full behaviour deliberately: the default suspends the pool, which stops every volume in it, including the database that depends on it.

Metadata Recovery

lvs -a -o+lv_health_status vg0
thin_check /dev/vg0/thinpool_tmeta
thin_repair -i bad_tmeta -o good_tmeta

If the kernel could not cleanly close the pool, it flags needs_check and the next activation performs a check. Learn thin_check/thin_repair now rather than during an incident - and keep a vgcfgbackup copy of the VG metadata outside the machine. Fragmentation is the other long-term cost: on-demand allocation across a busy pool degrades throughput compared with a fully provisioned LV, so thick LVs remain a reasonable choice for I/O-sensitive workloads such as iSCSI targets. Networking-side storage transports are covered in systemd-networkd VLAN/bond/bridge configuration, and virtualised guests that lean on these pools in Proxmox VE Linux bridge and VLAN setup.

原文链接：https://man7.org/linux/man-pages/man7/lvmthin.7.html