<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Aug 15, 2018 at 1:55 PM Richard W.M. Jones <<a href="mailto:rjones@redhat.com">rjones@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(Adding Stefan who implemented the subcommand)<br>
<br>
On Wed, Aug 15, 2018 at 12:44:44PM +0200, Kevin Wolf wrote:<br>
> Am 15.08.2018 um 12:26 hat Richard W.M. Jones geschrieben:<br>
> > On Tue, Aug 14, 2018 at 09:31:06PM +0300, Nir Soffer wrote:<br>
> > > On Tue, Aug 14, 2018 at 8:29 PM Richard W.M. Jones <<a href="mailto:rjones@redhat.com" target="_blank">rjones@redhat.com</a>><br>
> > > wrote:<br>
> > > <br>
> > > > This option prints the estimated size of the data that will be copied<br>
> > > > from the source disk.<br>
> > > ><br>
> > > > For interest, the test prints:<br>
> > > ><br>
> > > > 3747840 ../test-data/phony-guests/windows.img<br>
> > > > Estimate: 3710976<br>
> > > ><br>
> > > <br>
> > > Why not use qemu-img measure on the overlay?<br>
> > <br>
> > Yes this would be better, but oddly it doesn't work properly when<br>
> > the output format is set to 'raw':<br>
> > <br>
> >   /usr/bin/qemu-img 'measure' '-f' 'qcow2' '-O' 'raw' '--output=human' '/home/rjones/d/libguestfs/tmp/v2vovl62b7c2.qcow2'<br>
> >   required size: 6442450944<br>
> >   fully allocated size: 6442450944<br>
> > <br>
> > However it's OK if the output format is set to 'qcow2':<br>
> > <br>
> >   /usr/bin/qemu-img 'measure' '-f' 'qcow2' '-O' 'qcow2' '--output=human' '/home/rjones/d/libguestfs/tmp/v2vovla53d7c.qcow2'<br>
> >   required size: 1047986176<br>
> >   fully allocated size: 6443696128<br>
> > <br>
> > I guess it ignores sparseness of raw images, but I can't see a way to<br>
> > specify that on the command line.<br>
> > <br>
> > OTOH the qcow2 figure is probably a good enough guess for our purposes<br>
> > (ie. estimating how much data will be copied).<br>
> <br>
> 'qemu-img measure' calculates the resulting file size, not the number of<br>
> used blocks. I think this is because its main purpose is to create block<br>
> devices (like LVs) of the right size, so sparseness on a filesystem<br>
> level doesn't buy you anything.<br>
<br>
But if I run ‘qemu-img convert ... -O raw output.raw’ then output.raw<br>
will be a sparse file, and that's the file size I'd expect measure to<br>
give us for "required size" (of course "fully allocated size" would be<br>
the virtual size, and that is correct).<br>
<br>
It does look as if the block/raw-format.c:raw_measure function is wrong.<br>
<br>
In any case we can use the qcow2 estimate for our purposes as it will<br>
be near enough what we need (a rough estimate of the size of the copy).<br></blockquote><div><br></div><div>Yes, using qcow2 as output format looks like a good estimate. In our tests</div><div>it is always less then 1.1 * virtual size.</div><div><br></div><div>Nir</div></div></div>