[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: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC PATCH 2/4] block: add live block commit functionality
Date: Wed, 01 Aug 2012 09:07:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

Il 01/08/2012 08:32, Kevin Wolf ha scritto:
>>>> >>> +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.

Note that the latest version of mirroring has _two_ knobs:

1) granularity is what decides how much data could be written
unnecessarily, because of the dirty bitmap.

2) buffer size is what decides how much I/O is in flight at one time.

The default values are resp. the cluster size (or 64K for raw) and 10M.
 The two together give mirroring some self-tuning capability.  For
example in the first part of the mirroring you will likely proceed in
10M chunks with no concurrency; once you're synchronized, you'll
probably send several chunks, perhaps all 64K if the guest does random

Live commit as it is done now doesn't need any of this complication; it
is just a background operation that does not need to compete with the
guest.  So using a larger buffer is indeed always better, and 512K is a
nice intermediate value between mirroring's 64K and 10M extremes.

> 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?

We copy a cluster at a time, and that's also the resolution of
bdrv_is_allocated so we wouldn't gain anything.  Nice idea though, I had
to mull about it to find the flaw. :)


reply via email to

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