<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Mar 21, 2018 at 2:47 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">On Wed, Mar 21, 2018 at 11:20:13AM +0000, Nir Soffer wrote:<br>
> Hi,<br>
><br>
> I updated the random I/O documentation patch:<br>
> <a href="https://gerrit.ovirt.org/#/c/89022/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/89022/</a><br>
><br>
> I would to get your comments on this before we complete the implementation.<br>
<br>
I want to check a couple of things:<br>
<br>
(1) The OPTIONS request uses path ‘/images/%2A’ (ascii encoding of<br>
‘*’).  That is literally what is sent over the wire?<br></blockquote><div><br></div><div>Yes, you can send the upload path /images/ticket-uuid or the special /images/*</div><div><br></div><div>Both should behave in the same way.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(2) We can make the OPTIONS request without needing to send an<br>
Authorization header </blockquote><div><br></div><div>Authorization is always ignored, there is no need to send it to a server supporting<br></div><div>options.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">or having any ticket or disk in mind?  This is<br>
necessary because the NBD protocol requires us to send back the<br>
'can-trim' (etc) flags very early on, long before we have created a disk.<br></blockquote><div><br></div><div>Then you should use the special /images/* that does not require a ticket or</div><div>an image.</div><div><br></div><div>But not that trim will do nothing in the first version, and later it will be useful</div><div>only for images on file storage, and some images on block storage (depending</div><div>if the user selected wipe-after-delete). This is explain in the section about</div><div>trim.</div><div><br></div><div>Even when trim will be implemented for some image, it may not zero data.</div><div><br></div><div>I hope that the semantics match what qemu-img/nbdkit expects? </div><div><br></div><div>If we cannot implement a useful trim now, maybe we should not implement</div><div>it at all, so virt-v2v cat tell that trim is not supported using OPTIONS?</div><div><br></div><div>Nir</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Rich.<br>
<br>
--<br>
Richard Jones, Virtualization Group, Red Hat <a href="http://people.redhat.com/~rjones" rel="noreferrer" target="_blank">http://people.redhat.com/~rjones</a><br>
Read my programming and virtualization blog: <a href="http://rwmj.wordpress.com" rel="noreferrer" target="_blank">http://rwmj.wordpress.com</a><br>
Fedora Windows cross-compiler. Compile Windows programs, test, and<br>
build Windows installers. Over 100 libraries supported.<br>
<a href="http://fedoraproject.org/wiki/MinGW" rel="noreferrer" target="_blank">http://fedoraproject.org/wiki/MinGW</a><br>
</blockquote></div></div>