qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 2/3] block: resize backing image during activ


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH v3 2/3] block: resize backing image during active layer commit, if needed
Date: Thu, 23 Jan 2014 15:05:49 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 01/23/2014 02:48 PM, Jeff Cody wrote:
> If the top image to commit is the active layer, and also larger than
> the base image, then an I/O error will likely be returned during
> block-commit.
> 
> For instance, if we have a base image with a virtual size 10G, and a
> active layer image of size 20G, then committing the snapshot via
> 'block-commit' will likely fail.
> 
> This will automatically attempt to resize the base image, if the
> active layer image to be committed is larger.
> 
> Signed-off-by: Jeff Cody <address@hidden>
> Reviewed-by: Eric Blake <address@hidden>

> +    if (length > base_length) {
> +        if (bdrv_truncate(base, length) < 0) {
> +            error_setg(errp, "Top image %s is larger than base image %s, and 
> "
> +                             "resize of base image failed",
> +                             bs->filename, base->filename);
> +            goto error_restore_flags;
> +        }
> +    } else if (length < 0) {
> +        goto error_restore_flags;
> +    }
> +
> +
>      bdrv_ref(base);
>      mirror_start_job(bs, base, speed, 0, 0,
>                       on_error, on_error, cb, opaque, errp,
>                       &commit_active_job_driver, false, base);
> +    if (error_is_set(errp)) {
> +        goto error_restore_flags;

If we get here, bdrv_truncate() succeeded at enlarging the base file.  A
full rollback would imply adding a second bdrv_truncate() in the error
handling path to undo the growth back to the original size (of course,
ignoring failure to shrink).  But that's more complex, and probably not
worth adding in (at any rate, leaving the base file larger doesn't
affect semantics of the bytes seen by the guest, and for file formats
that handle resizing via a sparse tail doesn't even consume much
storage).  So my R-b stands.

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