LVM Snapshot Merge: Data Consistency During Online Rollback

Answer

The Linux kernel does not guarantee a consistent point-in-time state for an entire volume after an online merge if writes occurred during the process. The merge operation is not atomic in the traditional sense—it proceeds as a background block-level restoration that can be interrupted by concurrent I/O.

Thick vs. Thin Snapshot Merge Behavior

For thick-provisioned snapshots, the merge copies blocks from the snapshot back to the origin. When the origin receives writes during this process, the kernel typically preserves the latest write to each block, meaning the restored snapshot data may be immediately overwritten for blocks that were modified concurrently. This creates a hybrid state that is neither the original snapshot nor the fully updated volume.

Thin-provisioned snapshots handle merges differently. Instead of copying data blocks, the merge updates block mappings in the thin pool metadata to point back to the original data. This reduces I/O overhead significantly but still does not prevent write collisions—concurrent writes to blocks being remapped can result in inconsistent metadata states.

Constraints and Risks

• I/O Contention: Thick snapshot merges consume substantial bandwidth, potentially degrading application performance.
• Write Collision: Blocks modified during a merge may end up in an inconsistent state, especially if the filesystem cannot tolerate partial updates.
• Space Exhaustion: If the snapshot's COW space is exhausted before the merge completes, the operation fails and the volume becomes unrecoverable via that snapshot.

Recommendations

1. Quiesce the application or remount the filesystem as read-only before initiating a merge to ensure consistency.
2. Use thin snapshots when possible, as they reduce I/O load during merge operations.
3. Monitor COW space usage during thick snapshot merges to prevent overflow.
4. Verify the final state after merge using filesystem checks or checksums if data integrity is critical.

One missing diagnostic detail: What filesystem are you using on the volume? Journaling filesystems like ext4 or XFS provide better resilience to partial merges, while non-journaled filesystems are more vulnerable to corruption.