You probably created an LVM snapshot to back up a database or run a quick test, and everything seemed fine until the performance cratered. Most people treat snapshots like a free ‘undo’ button, but they’re really a ticking clock. If that snapshot fills up, the origin volume goes offline. I’ve seen more than one production outage because a stale snapshot silently ballooned and locked the partition.

Why snapshots kill your I/O performance

When you write to the original volume, LVM has to copy the old data to the snapshot space first. That’s a classic copy-on-write tax. If you’re doing heavy writes, you’re effectively doubling your disk I/O latency. Even if the snapshot is small, the metadata overhead can start to feel like walking through mud. Most folks don’t realize their latency spikes are just the kernel doing busywork in the background.

lvs -o lv_name,lv_size,data_percent,origin

• Monitor your data_percent metrics with a cron script or Telegraf
• Delete snapshots as soon as the backup job finishes
• Never leave a snapshot active during heavy write-intensive tasks
• Set up an alert threshold at 80 percent before you hit the cliff

The silent death of the origin volume

Here is the part that hurts: when that snapshot overflows, the whole volume freezes. It doesn’t matter if your root partition is fine; if your data drive’s snapshot hits capacity, the kernel pauses all I/O to prevent corruption. Next time you see a hung process waiting on D-state, check your lvs output before you try a reboot that might make the data loss permanent.

If you really need snapshots for production work, just migrate to ZFS or Btrfs. LVM snapshots are legacy tech that wasn’t built for modern, high-churn workloads. They are fine for a quick clone before a config change, but don’t trust them for anything you’d actually miss.