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

[Nir Soffer]

On Mon, Mar 12, 2018 at 9:13 AM Nir Soffer <nirsof at gmail.com> wrote:

> 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.
>

I posted this
https://gerrit.ovirt.org/#/c/88793/

If this work for you I think we can include this in the next 4.2 build.

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