[Libguestfs] [PATCH v6] v2v: Add -o rhv-upload output mode.

[Eric Blake]

On 03/21/2018 03:08 PM, Nir Soffer wrote:
> On Wed, Mar 21, 2018 at 3:34 PM Richard W.M. Jones <rjones at 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