[Libguestfs] [PATCH v4 0/3] v2v: Add -o rhv-upload output mode.

[Nir Soffer]

On Fri, Mar 9, 2018 at 4:25 PM Richard W.M. Jones <rjones at redhat.com> wrote:

> It has to be said it would be really convenient to have a 'zero'
> and/or 'trim' method of some sort.
>

'trim' means discard?

Currently we cannot support discard on block storage since ovirt may need
to wipe
lvs when deleting a disk, and discarding may leave unwiped user data. This
may
change in 4.3 if we switch to wipe on creation instead of wipe after delete.


> qemu-img tries hard to trim the whole disk before using it.
> Unfortunately it does this in different ways across RHEL 7 and
> upstream.  With upstream I managed a workaround based on ignoring any
> zero requests which arrive before the first write.  However it's not
> so easy to do this for RHEL 7's qemu which is issuing mixed writes and
> zeroes in different orders.
>
> How hard would it be to implement a special https request in imageio
> for zeroing (better still, either zeroing or trimming) a range of
> bytes?
>

Supporting efficient zero makes sense. We plan to support it via a special
sparse format, see:
https://gerrit.ovirt.org/#/c/85413/

We have a demo here:
https://gerrit.ovirt.org/#/c/85468/

This will not help you use case when you want to mix read/write/zero
requests,
but we can use the same infrastructure. We plan to use fallocate for file
based
storage:
https://gerrit.ovirt.org/#/c/85512/
and BLKZEROOUT for block storage:
https://gerrit.ovirt.org/#/c/85537/
and some dumb zero loop if these options are not available.

So we need to map the zero operation to http - how about:

POST /images/ticket-id ...
...
{
    "op": "zero",
    "offset": X,
    "size": Y
}

I would like to support only aligned offset and size - do you think it
should work
for qemu-img?

Adding this with dumb zero loop can be done quickly. We can make it more
efficient later.

Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20180312/5da2b167/attachment.htm>