Re: [Libguestfs] [PATCH v6] v2v: Add -o rhv-upload output mode.
On 03/21/2018 03:08 PM, Nir Soffer wrote:
On Wed, Mar 21, 2018 at 3:34 PM Richard W.M. Jones
<rjones(a)redhat.com>
wrote:
> PROBLEMS:
> - -of qcow2 does not work, with multiple problems
> * needs to set NBD size to something larger than virtual size
[snip] [By the way, it's okay to delete pages of uninteresting quoted
material, so that readers can get to the meat of your reply a lot faster]
> +def pwrite(h, buf, offset):
> + count = len(buf)
> + h['highestwrite'] = max(h['highestwrite'], offset+count)
> + real_pwrite(h, buf, offset, count)
> +
> +def real_pwrite(h, buf, offset, count):
> + http = h['http']
> + transfer=h['transfer']
> + transfer_service=h['transfer_service']
> +
> + http.putrequest("PUT", h['path'])
>
This will always flush - if you want to avoid flushing (you try to avoid in
zero), you need to specify:
h["path"] + "?flush=n"
(not implemented yet but will be)
If we start using ?flush=n on write, then we'd need to properly honor
flush requests (instead of not passing them on because everything has
already been flushed per operation) - perhaps room for future improvements.
+
> +def zero(h, count, offset, may_trim):
>
What is may_trim? trim can never replace zero.
If may_trim is true, the plugin may use trim or other means instead of
manually writing out zeroes, provided that the trimmed region is
guaranteed to read back as zeroes (that is, you can punch holes). If
may_trim is false, the plugin MUST write zeroes instead of punching
holes. If trim does not read back as zero (or you don't have other
means of punching holes), then you can ignore the parameter, and just
always manually write zeroes.
> + http = h['http']
> + transfer=h['transfer']
> + transfer_service=h['transfer_service']
> +
> + # Unlike the trim and flush calls, there is no 'can_zero' method
>
Do you mean h["can_zero"] set in getoptions()?
nbdkit has not yet had a need to create a can_zero callback - it always
advertises zero support to the end client (unless you use --filter
nozero), and nbdkit is just fine doing the fallback to calling pwrite if
the plugin lacks a zero callback, or if the zero callback fails with an
error value of EOPNOTSUPP. (Which is also a handy trick - you can code
your plugin's zero implementation to always punch holes, and then merely
fail up front with EOPNOTSUPP if may_trim is false, rather than having
to teach your plugin to manually write zeroes)
But if having a plugin .can_zero callback to make it easier for a plugin
to always have a .zero callback, but to opt out of having it ever called
(because it is conditional on something learned at connect time, such as
whether the remote server supports zeroing), then that's a good argument
for enhancing the plugin interface. (I already was in the process of
adding a filter .can_zero callback, so having a counterpart callback in
the plugin isn't that much harder).
> +def emulate_zero_with_pwrite(h, count, offset):
I'm not sure whether it is smarter to have zero fail with EOPNOTSUPP and
let nbdkit call pwrite natively, instead of trying to fall back at this
level (then again, this level may have some optimizations over what
repeated calls from nbdkit to pwrite might see).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org