<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Apr 10, 2018 at 4:48 PM Kevin Wolf <<a href="mailto:kwolf@redhat.com">kwolf@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 10.04.2018 um 15:03 hat Nir Soffer geschrieben:<br>
> On Tue, Apr 10, 2018 at 1:44 PM Richard W.M. Jones <<a href="mailto:rjones@redhat.com" target="_blank">rjones@redhat.com</a>><br>
> wrote:<br>
><br>
> > We now have true zeroing support in oVirt imageio, thanks for that.<br>
> ><br>
> > However a problem is that ‘qemu-img convert’ issues zero requests for<br>
> > the whole disk before starting the transfer.  It does this using 32 MB<br>
> > requests which take approx. 1 second each to execute on the oVirt side.<br>
><br>
><br>
> > Two problems therefore:<br>
> ><br>
> > (1) Zeroing the disk can take a long time (eg. 40 GB is approx.<br>
> >     20 minutes).  Furthermore there is no progress indication while this<br>
> >     is happening.<br>
> ><br>
><br>
> >     Nothing bad happens: because it is making frequent requests there<br>
> >     is no timeout.<br>
> ><br>
> > (2) I suspect that because we don't have trim support that this is<br>
> >     actually causing the disk to get fully allocated on the target.<br>
> ><br>
> >     The NBD requests are sent with may_trim=1 so we could turn these<br>
> >     into trim requests, but obviously cannot do that while there is no<br>
> >     trim support.<br>
> ><br>
><br>
> It sounds like nbdkit is emulating trim with zero instead of noop.<br>
><br>
> I'm not sure why qemu-img is trying to do, I hope the nbd maintainer on<br>
> qemu side can explain this.<br>
<br>
qemu-img tries to efficiently zero out the whole device at once so that<br>
it doesn't have to use individual small write requests for unallocated<br>
parts of the image later on.<br></blockquote><div><br></div><div>This makes sense if the device is backed by a block device on oVirt side,</div><div>and the NBD support efficient zeroing. But in this case the device is backed</div><div>by an empty sparse file on NFS, and oVirt does not support yet efficient</div><div>zeroing, we just write zeros manually.</div><div><br></div><div>I think should be handled on virt-v2v plugin side. When zeroing a file raw image,</div><div>you can ignore zero requests after the highest write offset, since the plugin</div><div>created a new image, and we know that the image is empty.</div><div><br></div><div>When the destination is a block device we cannot avoid zeroing since a block</div><div>device may contain junk data (we usually get dirty empty images from our local</div><div>xtremio server).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The problem is that the NBD block driver has max_pwrite_zeroes = 32 MB,<br>
so it's not that efficient after all. I'm not sure if there is a real<br>
reason for this, but Eric should know.<br></blockquote><div><br></div><div>We support zero with unlimited size without sending any payload to oVirt, so </div><div>there is no reason to limit zero request by max_pwrite_zeros. This limit may</div><div>make sense when zero is emulated using pwrite.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> However, since you suggest that we could use "trim" request for these<br>
> requests, it means that these requests are advisory (since trim is), and<br>
> we can just ignore them if the server does not support trim.<br>
<br>
What qemu-img sends shouldn't be a NBD_CMD_TRIM request (which is indeed<br>
advisory), but a NBD_CMD_WRITE_ZEROES request. qemu-img relies on the<br>
image actually being zeroed after this.<br></blockquote><div><br></div><div>So it seems that may_trim=1 is wrong, since trim cannot replace zero.</div><div><br></div><div>Nir</div><div> </div></div></div>