On Tue, Apr 18, 2017 at 01:31:11PM +0200, Michal Privoznik wrote: > On 04/18/2017 01:03 PM, Vasiliy Tolstov wrote: > > 2017-04-18 8:39 GMT+03:00 Michal Privoznik <mprivozn@xxxxxxxxxx>: > > > s that right? Here I'm successfully cloning a volume across two storage pools: > > > > > > Yes, it works but.... > > Source image: > > image: /var/lib/libvirt/images/sda/143177 > > file format: qcow2 > > virtual size: 5.0G (5368709120 bytes) > > disk size: 902M > > cluster_size: 65536 > > Format specific information: > > compat: 0.10 > > refcount bits: 16 > > > > Dest image: > > image: /var/lib/libvirt/images/sda/test > > file format: qcow2 > > virtual size: 5.0G (5368709120 bytes) > > disk size: 902M > > cluster_size: 65536 > > Format specific information: > > compat: 0.10 > > refcount bits: 16 > > > > > > But > > -rw------- 1 root 908M Apr 18 13:59 143177 > > -rw------- 1 root 902M Apr 18 13:59 test > > > > Why size is changed on destination image? In case of cp > > --spwarse=always size does not changed. > > > > That's because libvirt does not use `cp` to copy the disk images. We use > qemu-img for copying. And we do not guarantee that the disk structure does > not change. We guarantee that the data stored on the disk doesn't change. > Otherwise we wouldn't be able to convert disk images. > > NB, with sparse files - it's not as straightforward either. Some filesystems > may decide that the hole is not big enough so they do allocate it actually. > XFS is a very good example of such behaviour. So the data/hole structure of > a file may not line up with the structure of a copy. Although, the data as > read from the files are the same. XFS will also do speculative allocation of filesystem blocks which have not yet had data written to them, on the basis that a future write might need them soon. So you can't really compare allocation disk size at all. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
