qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 2/3] qcow2: Implement bdrv_amend_options


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v2 2/3] qcow2: Implement bdrv_amend_options
Date: Thu, 29 Aug 2013 06:45:17 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8

On 08/29/2013 05:20 AM, Max Reitz wrote:
> Implement bdrv_amend_options for compat, size, backing_file, backing_fmt
> and lazy_refcounts.
> 
> Downgrading images from compat=1.1 to compat=0.10 is achieved through
> handling all incompatible flags accordingly, clearing all compatible and
> autoclear flags and expanding all zero clusters.
> 
> Signed-off-by: Max Reitz <address@hidden>
> ---

> +/*
> + * Expands all zero clusters on the image; important for downgrading to a 
> qcow2
> + * version which doesn't yet support metadata zero clusters.

Do we have to fully write 0 blocks into the image no matter what, or are
there cases where, when the file has a backing image and we know the
backing image has 0 bytes at the same offset, where we could flatten by
removing the cluster and letting the reference defer to the backing
file?  It's always safer to write 0 blocks into this image, but it may
be worth considering whether we need the (ability) to try the alternate
method as it results in a smaller file and potentially faster conversion.


> +
> +    /* the refcount order might be different in newer images - however, qemu
> +     * doesn't support anything different than 4 anyway, so nothing to fix
> +     * there */

This sounds risky.  Wouldn't it be safer to error out if the image
didn't have a refcount order of 4, than to just ignore it; on the
grounds that if qemu DOES add support for non-4 refcount order, an error
will at least alert someone to the fact that they need to add some
(potentially complicated) code here?

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