qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support f


From: Dor Laor
Subject: Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support for replication]
Date: Thu, 24 May 2012 18:32:12 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

On 05/24/2012 05:19 PM, Paolo Bonzini wrote:
Il 24/05/2012 16:00, Ori Mamluk ha scritto:

The dirty bitmap is managed by these QMP commands:

* blockdev-dirty-enable: takes a file name used for the dirty bitmap,
and an optional granularity.  Setting the granularity will not be
supported in the initial version.

* query-block-dirty: returns statistics about the dirty bitmap: right
now the granularity, the number of bits that are set, and whether QEMU
is using the dirty bitmap or just adding to it.

* blockdev-dirty-disable: disable the dirty bitmap.


When do bits get cleared from the bitmap?

drive-mirror clears bits from the bitmap as it processes the writes.

In addition to the persistent dirty bitmap, QEMU keeps an in-flight
bitmap.  The in-flight bitmap does not need to be persistent.


Here is how the bitmaps are handled when doing I/O on the source:
- after writing to the source:
   - clear bit in the volatile in-flight bitmap
   - set bit in the persistent dirty bitmap

- after flushing the source:
   - msync the persistent bitmap to disk


Here is how the bitmaps are handled in the drive-mirror coroutine:
- before reading from the source:
   - set bit in the volatile in-flight bitmap

- after writing to the target:
   - if the dirty count will become zero, flush the target
   - if the bit is still set in the in-flight bitmap, clear bit in the
     persistent dirty bitmap
   - clear bit in the volatile in-flight bitmap

I didn't understand whether the persistent dirty bitmap needs to be flushed. This bitmap actually control the persistent known state of the destination image. Since w/ mirroring we always have the source in full state condition, we can choose to lazy update the destination w/ a risk of loosing some content from the last flush (of the destination only side).

This way one can pick the frequency of flushing the persistent bits map (and the respective target IO writes). Continuous replication can chose a timely based fashion, such as every 5 seconds. A standard mirroring job for live copy proposes can pick just to flush once at the end of the copy process.

Dor

"using the dirty bitmap or just adding to it" - I'm not sure I
understand what you mean. what's the difference?

Processing the data and removing from the bitmap (mirroring active), or
just setting dirty bits (mirroring inactive).

Paolo





reply via email to

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