Re: [Libguestfs] [PATCH 2/6] v2v: rhv-upload-plugin: Use API_VERSION 2

On Sat, Jan 23, 2021 at 04:57:20PM +0200, Nir Soffer wrote: > On Sat, Jan 23, 2021 at 2:22 PM Richard W.M. Jones <rjones(a)redhat.com&gt; wrote: > > > > On Sat, Jan 23, 2021 at 02:02:16PM +0200, Nir Soffer wrote: > > > > > > > > > On Sat, Jan 23, 2021, 08:28 Richard W.M. Jones <rjones(a)redhat.com&gt; wrote: > > > > > > On Sat, Jan 23, 2021 at 12:45:20AM +0200, Nir Soffer wrote: > > > > @failing > > > > -def pwrite(h, buf, offset): > > > > +def pwrite(h, buf, offset, flags): > > > > http = h['http'] > > > > > > > > count = len(buf) > > > > @@ -234,7 +253,7 @@ def pwrite(h, buf, offset): > > > > > > > > > > > > @failing > > > > -def zero(h, count, offset, may_trim): > > > > +def zero(h, count, offset, flags): > > > > > > Assume there's no way to pass the possible FUA flag through to oVirt here? > > > > > > > > > We have flush=true, which send nbd flush command after the write/zero. > > > > > > Maybe we could handle flush=true as fua when using nbd backend, I'm not sure > > > how important is this. > > > > > > I think we miss converting fua to flush=true to have full api 2 support. > > > > Any copy program ought not to set this flag on general writes/zeroes, > > so it's not really important for pwrite/zero, but a nice to have. > > Also we don't report can_fua, so the client is not allowed to send the fua > flag. Ignoring the fua flag is correct. Hmm, very true.

> > However nbdcopy has a --flush flag which sends a flush command to the > > destination when the copy has finished. We ought to obey this one.\ > > Sure, but this is handled by flush(). Agreed. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top