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

On Fri, Mar 9, 2018 at 4:25 PM Richard W.M. Jones <rjones(a)redhat.com&gt; 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.