LVM Snapshot Merge Stuck? Here's the Real Fix

1. The Snapshot Volume Is Still Active (Most Common Cause)

Nine times out of ten when I see a merge fail, it's because the snapshot is still mounted or active. The system won't merge an active snapshot—it's a safety thing. I had a client last month whose backup script left a snapshot mounted, and the merge just sat there for hours saying "Merge pending."

Check if the snapshot is active

lvs

Look at the output. The snapshot will have a "S" under Attr. If it's active, you'll see something like:

LV        VG   Attr       LSize
mysnap    vg0  swi-a-s--- 10.00g

That "a" in Attr means it's active. You need to deactivate it first.

How to fix it

lvchange -an /dev/vg0/mysnap

That deactivates the snapshot. Then start the merge:

lvconvert --merge /dev/vg0/mysnap

If the original volume is mounted, the merge will happen on next reboot or when you unmount the original. For a live system, you can unmount the original, run the merge, then remount:

umount /dev/vg0/original
lvconvert --merge /dev/vg0/mysnap
mount /dev/vg0/original /mountpoint

The merge runs in the background. Use lvs again to watch progress. When the snapshot disappears from the list, the merge is done.

2. Not Enough Free Space in the Volume Group

Snapshots need room to track changes during the merge. If your volume group is tight on space, the merge will pause or fail with an error like "Insufficient free space." I've seen this happen when someone created a large snapshot on a nearly full VG—real mess to clean up.

How to check available space

vgs

Look under VFree. If it's less than 10% of the snapshot size, you're in trouble. The merge needs at least the snapshot size in free space, sometimes more depending on how many changes happened.

The fix: extend the volume group

You got a few options:

• Add a new disk or partition: vgextend vg0 /dev/sdb1
• Resize the snapshot down (if it's larger than needed): This is risky. I'd only do it if you're confident the snapshot has little data. Use lvreduce -L 5G /dev/vg0/mysnap but keep in mind you can't shrink below used space.
• Free up space in the VG by removing unused logical volumes. Check with lvs and delete anything you don't need.

Once you have enough free space, the merge will resume automatically if it was pending. If not, restart it:

lvconvert --merge /dev/vg0/mysnap

3. The Original Volume Is Still in Use (Mounted or Has Open Files)

This one's sneaky. Even if the snapshot is inactive, the original volume might have open files that prevent the merge. The system won't merge a volume that's in use because it'd break running processes. I've had a database server refuse to merge because MySQL had a file lock on the volume.

How to check for open files

lsof | grep /dev/vg0/original

If you see anything there, those processes need to stop. For a database like MySQL, you'll need to shut it down gracefully:

systemctl stop mysql

Force the merge (careful now)

If you can't unmount but need the merge to happen, you can force it with --force:

lvconvert --merge --force /dev/vg0/mysnap

This will mark the merge for next boot. The system will unmount the volume during reboot, run the merge, then remount. I don't love this approach because it means a reboot, but sometimes that's the only way. Only do this if you're sure the data is safe.

If you force it and the system won't boot, you can enter recovery mode and check the volume with fsck:

fsck /dev/vg0/original

Quick-Reference Summary Table

That's it. No magic, just logic. LVM merge failures are almost always one of these three things. Check them in order, and you'll be back up in ten minutes.