qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 17/20] block: support a persistent dirty bitmap


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 17/20] block: support a persistent dirty bitmap
Date: Thu, 20 Dec 2012 16:03:38 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 12/12/2012 06:46 AM, Paolo Bonzini wrote:
> Signed-off-by: Paolo Bonzini <address@hidden>
> ---
>  block.c     | 133 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
>  block.h     |   5 +++
>  block_int.h |   5 +++
>  3 files changed, 141 insertions(+), 2 deletions(-)
> 

> +void bdrv_enable_persistent_dirty_tracking(BlockDriverState *bs, const char 
> *file,
> +                                           Error **errp)
> +{
> +    int rc;
> +    int granularity_bits;
> +    int64_t bitmap_size;
> +    size_t file_size;
> +    QEMUMmapArea mm;
> +    HBitmap *new_bitmap;
> +    bool load;
> +
> +    assert(bs->dirty_usage > 0);
> +
> +    granularity_bits = hbitmap_granularity(bs->dirty_bitmap);
> +    bitmap_size = (bdrv_getlength(bs) >> BDRV_SECTOR_BITS);
> +    file_size = hbitmap_required_size(bitmap_size, granularity_bits);
> +
> +    load = access(file, R_OK) >= 0;
> +    if (bdrv_in_use(bs) && load) {
> +        error_set(errp, QERR_DEVICE_IN_USE, bdrv_get_device_name(bs));
> +        return;
> +    }
> +
> +    /*
> +     * Do not touch fields in BS until we're sure we can complete
> +     * successfully.
> +     */
> +    rc = qemu_mmap_alloc(&mm, file, file_size);
> +    if (rc < 0) {
> +        error_set(errp, QERR_OPEN_FILE_FAILED, file);
> +        return;
> +    }
> +
> +    new_bitmap = hbitmap_alloc_with_data(bitmap_size, granularity_bits, 
> mm.mem);
> +    if (!load) {
> +        hbitmap_copy(new_bitmap, bs->dirty_bitmap);

Here's where my comment earlier in the series, about
hbitmap_alloc_with_data repopulating the upper layers of the hbitmap on
reused data, becomes essential.  But since that fix is earlier in the
series, and I didn't see anything else suspicious in this patch, you can
add:

Reviewed-by: Eric Blake <address@hidden>

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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