[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for-2.12 0/4] qmp dirty bitmap API

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-devel] [PATCH for-2.12 0/4] qmp dirty bitmap API
Date: Thu, 16 Nov 2017 11:17:55 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

16.11.2017 00:20, John Snow wrote:

On 11/13/2017 11:20 AM, Vladimir Sementsov-Ogievskiy wrote:
Hi all.

There are three qmp commands, needed to implement external backup API.

Using these three commands, client may do all needed bitmap management by

on backup start we need to do a transaction:
  {disable old bitmap, create new bitmap}

on backup success:
  drop old bitmap

on backup fail:
  enable old bitmap
  merge new bitmap to old bitmap
  drop new bitmap

Can you give me an example of how you expect these commands to be used,
and why they're required?

I'm a little weary about how error-prone these commands might be and the
potential for incorrect usage seems... high. Why do we require them?

It is needed for incremental backup. It looks like bad idea to export abdicate/reclaim functionality, it is simpler
and clearer to allow user to merge/enable/disable bitmaps by hand.

usage is like this:

1. we have dirty bitmap bitmap0 for incremental backup.

2. prepare image fleecing (create temporary image with backing=our_disk)
3. in qmp transaction:
    - disable bitmap0
    - create bitmap1
    - start image fleecing (backup sync=none our_disk -> temp_disk)
4. export temp_disk (it looks like a snapshot) and bitmap0 through NBD

=== external tool can get bitmap0 and then copy some clusters through NBD ===

on successful backup external tool can drop bitmap0. or can save it and reuse somehow

on failed backup external tool can do the following:
    - enable bitmap0
    - merge bitmap1 to bitmap0
    - drop bitmap1

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]