You probably set up an LVM snapshot for a quick backup job, assuming it was a low-cost metadata operation. It works fine on an idle dev box, but in production, I have seen this silently crush IOPS once the copy-on-write overhead piles up. You don’t notice it until the latency spikes, at which point your database is already effectively offline.

Why your disk queue depth is screaming

When you create a snapshot, LVM allocates space for the exception table. Every time a block changes in the original volume, LVM has to copy the old data to the snapshot area before the write completes. If your change rate is high, this turns every single write into a double write operation. It hits your disk throughput twice, and if your backend storage can’t keep up with that latency, your whole app stack crawls to a halt.

lvs -o +seg_pe_ranges,snap_percent

• Check the snap_percent field frequently to see how much of your allocated COW area is actually filled.
• Ensure your COW volume is on a different physical spindle or SSD array to split the IO pressure.
• Keep your snapshot window short because a full snapshot volume will simply drop and invalidate the snapshot entirely.

If you are running write-heavy workloads, consider moving to a filesystem that handles snapshots at the subvolume or block level like ZFS or Btrfs. If you absolutely must use LVM, monitor your device mapper latency using iostat. If you see the latency climb immediately after taking a snapshot, don’t wait for a crash; prune that snapshot and reconsider your backup architecture before it hits you again.