[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 2/4] block: add live block commit functional
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [RFC PATCH 2/4] block: add live block commit functionality |
Date: |
Wed, 01 Aug 2012 08:32:54 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 |
Am 31.07.2012 19:55, schrieb Jeff Cody:
> On 07/31/2012 01:51 PM, Eric Blake wrote:
>> On 07/30/2012 11:16 PM, Jeff Cody wrote:
>>> This adds the live commit coroutine. This iteration focuses on the
>>> commit only below the active layer, and not the active layer itself.
>>>
>>> The behaviour is similar to block streaming; the sectors are walked
>>> through, and anything that exists above 'base' is committed back down
>>> into base. At the end, intermediate images are deleted, and the
>>> chain stiched together. Images are restored to their original open
>>
>> s/stiched/stitched/
>>
>>> +
>>> +enum {
>>> + /*
>>> + * Size of data buffer for populating the image file. This should be
>>> large
>>> + * enough to process multiple clusters in a single call, so that
>>> populating
>>> + * contiguous regions of the image is efficient.
>>> + */
>>> + COMMIT_BUFFER_SIZE = 512 * 1024, /* in bytes */
>>> +};
>>
>> Paolo's latest round of patches got to the point of making this
>> configurable for drive-mirror; is that something you should be copying here?
>
> Yes
Though its use is very limited for live commit. For the mirror it's
important because a larger number can mean that more data is
unnecessarily written, and the target can become larger than the source.
For live commit, I think using a larger buffer is always better.
Hm, part of the difference is that I assume that commit uses
bdrv_is_allocated() to check whether some data must really be copied.
But then, there's no reason why mirroring couldn't do that as well. Paolo?
Kevin
- Re: [Qemu-devel] [RFC PATCH 2/4] block: add live block commit functionality,
Kevin Wolf <=