Bug 1298605 - [RFE] Live Merge: Merge adjacent snapshots concurrently
[RFE] Live Merge: Merge adjacent snapshots concurrently
Status: CLOSED WONTFIX
Product: vdsm
Classification: oVirt
Component: RFEs (Show other bugs)
4.17.19
Unspecified Unspecified
low Severity low (vote)
: ovirt-4.2.0
: ---
Assigned To: Ala Hino
Raz Tamir
: FutureFeature, Performance
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-14 09:32 EST by Adam Litke
Modified: 2017-06-11 09:16 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-06-11 09:16:03 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ylavi: ovirt‑4.2?
amureini: planning_ack?
amureini: devel_ack?
amureini: testing_ack?


Attachments (Terms of Use)

  None (edit)
Description Adam Litke 2016-01-14 09:32:28 EST
The qemu and libvirt live merge APIs allow the contents of multiple adjacent snapshots to be merged with a single operation.  If engine knows that multiple snapshots are going to be deleted it should submit them all in a single 'merge' call so the merging can be done more efficiently by qemu.

Take the example chain: A-B-C (A is the base and C is the active layer)

This chain has two snapshots (preserved in volumes A and B).  Today if we wanted to reduce this chain to a single volume we would use two merge calls:

merge(base=A, top=B) and merge(base=A, top=C)
(If we removed the oldest snapshot first)

-or-

merge(base=B, top=C) and merge(base=A, top=B)
(if we removed the newest snapshot first)

These two operations could be consolidated into a single merge(base=A, top=C) which would merge the data from B and C into A.

All of the live merge flows need to be evaluated to determine how they will work when multiple volumes are being merged simultaneously.
Comment 1 Yaniv Kaul 2016-01-17 06:02:12 EST
Can you quantify the improvement? If substantial, why is it 'low' ?
Comment 2 Adam Litke 2016-03-09 10:46:43 EST
(In reply to Yaniv Kaul from comment #1)
> Can you quantify the improvement? If substantial, why is it 'low' ?

The improvement is principally in user experience.  In cases where a VM has a lot of snapshots that need to be removed it can be labor intensive to "babysit" the merges and submit one after another.  I have not done tests to check the actual copy efficiency but we would be reducing a lot of round-trip calls back and forth between engine and vdsm, waiting for state transitions, etc.  I am sure qemu would copy more efficiently as well.

The severity is "low" because it currently works and this is not as important as block device watermark tracking during live merge.

Note You need to log in before you can comment on or make changes to this bug.