On Mon, Mar 12, 2018 at 9:13 AM Nir Soffer <nir...@gmail.com> wrote: > On Fri, Mar 9, 2018 at 4:25 PM Richard W.M. Jones <rjo...@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
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs