Am 15.08.2018 um 12:26 hat Richard W.M. Jones geschrieben: > On Tue, Aug 14, 2018 at 09:31:06PM +0300, Nir Soffer wrote: > > On Tue, Aug 14, 2018 at 8:29 PM Richard W.M. Jones <[email protected]> > > wrote: > > > > > This option prints the estimated size of the data that will be copied > > > from the source disk. > > > > > > For interest, the test prints: > > > > > > 3747840 ../test-data/phony-guests/windows.img > > > Estimate: 3710976 > > > > > > > Why not use qemu-img measure on the overlay? > > Yes this would be better, but oddly it doesn't work properly when > the output format is set to 'raw': > > /usr/bin/qemu-img 'measure' '-f' 'qcow2' '-O' 'raw' '--output=human' > '/home/rjones/d/libguestfs/tmp/v2vovl62b7c2.qcow2' > required size: 6442450944 > fully allocated size: 6442450944 > > However it's OK if the output format is set to 'qcow2': > > /usr/bin/qemu-img 'measure' '-f' 'qcow2' '-O' 'qcow2' '--output=human' > '/home/rjones/d/libguestfs/tmp/v2vovla53d7c.qcow2' > required size: 1047986176 > fully allocated size: 6443696128 > > I guess it ignores sparseness of raw images, but I can't see a way to > specify that on the command line. > > OTOH the qcow2 figure is probably a good enough guess for our purposes > (ie. estimating how much data will be copied).
'qemu-img measure' calculates the resulting file size, not the number of used blocks. I think this is because its main purpose is to create block devices (like LVs) of the right size, so sparseness on a filesystem level doesn't buy you anything. Kevin _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
