Skip to content

New strategy for incremental snapshots for CLVM-ng doesn't depend on bitmaps / checkpoint#137

Draft
Pearl1594 wants to merge 1 commit into
clvm-enhancementsfrom
clvm-enhancements-clvmng-inc-snaps
Draft

New strategy for incremental snapshots for CLVM-ng doesn't depend on bitmaps / checkpoint#137
Pearl1594 wants to merge 1 commit into
clvm-enhancementsfrom
clvm-enhancements-clvmng-inc-snaps

Conversation

@Pearl1594
Copy link
Copy Markdown
Member

Description

This PR introduces a new strategy for implementing incremental snapshots for clvm-ng

Stopped VM case:

  1. Create a staging LV: a fresh empty QCOW2 overlay backed by the current active LV
  2. Export the active LV to NFS: this becomes the new snapshot file (e.g. snap-2.qcow2)
  3. Rebase the staging LV: update its backing pointer from "the old active LV" to "snap-2 on NFS"
  4. Delete the old active LV: the VM disk is now the staging LV
  5. The staging LV is fresh (zero writes), so the next snapshot will only capture new changes

Running VM case:

  1. Create an LVM snapshot: lvcreate --snapshot takes a point-in-time block-level freeze of the LV. This is instantaneous and completely invisible to the VM. The VM keeps writing to the original LV; any blocks it
    overwrites get copied to the snapshot's CoW space first.
  2. Export the LVM snapshot to NFS while the VM runs normally: this becomes the new snapshot file
  3. Delete the LVM snapshot (it was only needed for the export window)
  4. Briefly pause the VM (< 1 second) and update the active LV's QCOW2 header to say "my backing is now snap-2 on NFS instead of snap-1", then resume
  5. Volume path in the database is unchanged: the same LV keeps serving the VM

The trade-off vs the stopped path: because the active LV is never replaced with a fresh one, its QCOW2 cluster table accumulates all writes over its lifetime. Each export captures those accumulated writes, so
snapshots grow over time rather than being truly minimal deltas. The data is always correct, just potentially larger than necessary.

Types of changes

  • Breaking change (fix or feature that would cause existing functionality to change)
  • New feature (non-breaking change which adds functionality)
  • Bug fix (non-breaking change which fixes an issue)
  • Enhancement (improves an existing feature and functionality)
  • Cleanup (Code refactoring and cleanup, that may add test cases)
  • Build/CI
  • Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

  • Major
  • Minor

Bug Severity

  • BLOCKER
  • Critical
  • Major
  • Minor
  • Trivial

Screenshots (if appropriate):

How Has This Been Tested?

How did you try to break this feature and the system with this change?

@Pearl1594 Pearl1594 requested a review from sureshanaparti May 27, 2026 20:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant