Re: [PATCH] Storage: Fix allocation for raw files.

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

 



On 09/02/2014 12:04 PM, Prerna Saxena wrote:
> When virsh vol-clone is attempted on a raw file where capacity > allocation,
> the resulting cloned volume has a size that matches the virtual-size of
> the parent; in place of matching its actual, disk size.
> For example : Given this image:
> [root@localhost]# qemu-img info /var/lib/libvirt/images/f20.raw
> image: /var/lib/libvirt/images/f20.raw
> file format: raw
> virtual size: 2.0G (2147483648 bytes)
> disk size: 617M
> 
> When this disk is copied using virsh vol-clone :
> [root@localhost~] vol-clone --vol f20.raw --newname f20-copy.raw
> --pool default
> Vol f20-copy.raw cloned from f20.raw
> [root@localhost~]
> 
> The characteristics of the cloned disk differ in "disk size".
> Its allocated disk size is more than the allocated size of parent file;
> which is an anomaly. It has picked up an allocated size matching
> the parent's virtual size.
> 
> [root@localhost~] qemu-img info /var/lib/libvirt/images/f20-copy.raw
> image: /var/lib/libvirt/images/f20-copy.raw
> file format: raw
> virtual size: 2.0G (2147483648 bytes)
> disk size: 2.0G
> 
> This patch fixes the cloned disk to have same _allocated_size_ as
> the parent file from which it was cloned.

A bug has been filed for this recently:
https://bugzilla.redhat.com/show_bug.cgi?id=1130739

It would be nice to mention it in the commit message.

> 
> Signed-off-by: Prerna Saxena <prerna@xxxxxxxxxxxxxxxxxx>
> ---
>  src/storage/storage_driver.c | 5 -----
>  1 file changed, 5 deletions(-)
> 
> diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c
> index 433d7b7..930b45a 100644
> --- a/src/storage/storage_driver.c
> +++ b/src/storage/storage_driver.c
> @@ -1821,11 +1821,6 @@ storageVolCreateXMLFrom(virStoragePoolPtr obj,
>      if (newvol->target.capacity < origvol->target.capacity)
>          newvol->target.capacity = origvol->target.capacity;
>  
> -    /* Make sure allocation is at least as large as the destination cap,
> -     * to make absolutely sure we copy all possible contents */
> -    if (newvol->target.allocation < origvol->target.capacity)
> -        newvol->target.allocation = origvol->target.capacity;
> -

This essentially reverts commit 5ea25b7 [1], which means requesting a clone
with <allocation> less than <capacity> will result in only the first
<allocation> bytes being copied, thus losing any data after that point.

The virStorageBackendCopyToFD call in createRawFile also needs to be adjusted
to copy the non-zero data after the 'allocation' position.

>      if (!backend->buildVolFrom) {
>          virReportError(VIR_ERR_NO_SUPPORT,
>                         "%s", _("storage pool does not support volume creation from an existing volume"));
> 

Jan

[1] http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=5ea25b7

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]