[libvirt] [PATCH 2/2] Storage : Fix cloning of raw, sparse volumes.

[Ján Tomko]

On Tue, May 05, 2015 at 08:47:56AM +0530, 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.
> This patch fixes the cloned disk to have same _allocated_size_ as
> the parent file from which it was cloned.
> 
> Reference: https://www.redhat.com/archives/libvir-list/2014-September/msg00064.html
> 
> Also fixes : https://bugzilla.redhat.com/show_bug.cgi?id=1130739
> 
> Signed-off-by: Prerna Saxena <prerna at linux.vnet.ibm.com>
> ---
>  src/storage/storage_backend.c | 2 +-
>  src/storage/storage_driver.c  | 5 -----
>  2 files changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c
> index 355fc7f..1a7c0cc 100644
> --- a/src/storage/storage_backend.c
> +++ b/src/storage/storage_backend.c
> @@ -429,7 +429,7 @@ createRawFile(int fd, virStorageVolDefPtr vol,
>      }
>  #endif
>  
> -    remain = vol->target.allocation;
> +    remain = inputvol->target.capacity;
>  

If we're not cloning a volume, inputvol is NULL and this will crash.

>      if (inputvol) {

After moving the assignment here, we will copy all the data from the input volume,
but we still use the original value of 'allocation' to fallocate the
start of the file.

So for an original 5GB file with 3 GB allocated (where + is an allocated
gigabyte):
  +_+_+
We'll end up with a file that has 4 GB allocated:
  +++_+
(We'll allocate the first 3 GB, and copy any remaining data)

I think we do not have to honor an allocation value less than the capacity
of the original volume and just assume it means 'create a sparse file'.

So I'd suggest:
1. setting the need_alloc to false if we're cloning a volume and the new
   allocation is less than the *original* capacity
2. making the fallocate call depend on need_alloc

>          /* allow zero blocks to be skipped if we've requested sparse

Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150505/12951f1c/attachment-0001.sig>