Re: [Libguestfs] [PATCH v2] v2v/v2v.ml: Use larger request size for -o rhv-upload

On 02/14/22 14:01, Richard W.M. Jones wrote: > But nbdcopy needs to be reworked to make the input and output requests > separate, so that nbdcopy will coalesce and split blocks as it copies. > This is difficult. > > Another problem I'm finding (eg > https://bugzilla.redhat.com/show_bug.cgi?id=2039255#c9) is that > performance of new virt-v2v is extremely specific to input and output > mode, and hardware and network configurations. For reasons that I > don't fully understand. How are the nbdcopy source and destination coupled with each other? From work I'd done a decade ago, I remember that connecting two network-oriented (UDP) processes with a small-buffer pipe between them caused very bad effects. Whenever either process was blocked on the network (or on a timer, for example), the pipe went immediately full or empty (dependent on the particular blocked process), which in turn blocked the other process almost immediately. So the mitigation for that was to create a simple local app, to be inserted between the two network-oriented processes in the pipeline, just to de-couple them from each other, and make sure that a write to the pipe, or a read from it, would effectively never block. (The app-in-the-middle did have a maximum buffer size, but it was configurable, so not a practical limitation; it could be multiple tens of MB if needed.) If nbdcopy does some internal queueing (perhaps implicitly, i.e. by allowing multiple requests to be in flight at the same time), then seeing some stats on those "in real time" could be enlightening.