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> 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
Attachments:
- attachment.html (text/html — 2.9 KB)