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