On Wed, Mar 21, 2018 at 2:47 PM Richard W.M. Jones <rjones@redhat.com> wrote:
On Wed, Mar 21, 2018 at 11:20:13AM +0000, Nir Soffer wrote:
> Hi,
>
> I updated the random I/O documentation patch:
> https://gerrit.ovirt.org/#/c/89022/
>
> I would to get your comments on this before we complete the implementation.

I want to check a couple of things:

(1) The OPTIONS request uses path ‘/images/%2A’ (ascii encoding of
‘*’).  That is literally what is sent over the wire?

Yes, you can send the upload path /images/ticket-uuid or the special /images/*

Both should behave in the same way.

(2) We can make the OPTIONS request without needing to send an
Authorization header

Authorization is always ignored, there is no need to send it to a server supporting
options.
 
or having any ticket or disk in mind?  This is
necessary because the NBD protocol requires us to send back the
'can-trim' (etc) flags very early on, long before we have created a disk.

Then you should use the special /images/* that does not require a ticket or
an image.

But not that trim will do nothing in the first version, and later it will be useful
only for images on file storage, and some images on block storage (depending
if the user selected wipe-after-delete). This is explain in the section about
trim.

Even when trim will be implemented for some image, it may not zero data.

I hope that the semantics match what qemu-img/nbdkit expects? 

If we cannot implement a useful trim now, maybe we should not implement
it at all, so virt-v2v cat tell that trim is not supported using OPTIONS?

Nir
 

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW