search for: nbd_opt_structured_repli

On 04/12/2018 05:24 AM, Richard W.M. Jones wrote: > I don't think we have nbd-server in RHEL, and in any case wouldn't it > be better to use qemu-nbd? > > You just start a new qemu-nbd process instead of faffing around with > configuration files, kill the qemu-nbd process when you're done, and > qemu-nbd supports qcow2 already. That, and qemu-nbd supports

Instead of repeating a check for valid reply headers in each sub-state machine, let's have a common helper function do all the work. Additionally, a central location will make it easier to uniformly capture any NBD_REP_ERR message payloads. --- generator/generator | 8 +-- generator/states-newstyle-opt-go.c | 40 +++----------

Time to enhance the nbd plugin to request structured replies from the server. For now, deal only with structured reads. The server can now return sparse reads, even though we need nbdkit version 3 before we can in turn return sparse reads back to the client. In general, we have to assume the server is malicious, and so we must sanity check that it sends replies we expect. Thus, we have a choice

Add a new negotiation feature where the client and server agree to use larger packet headers on every packet sent during transmission phase. This has two purposes: first, it makes it possible to perform operations like trim, write zeroes, and block status on more than 2^32 bytes in a single command. For NBD_CMD_READ, replies are still implicitly capped by the maximum block payload limits

This is about the simplest implementation of NBD Structured Replies (SR) that we can do right now. It accepts NBD_OPT_STRUCTURED_REPLIES when negotiated by the client, but only sends back the simplest possible SR when required to by NBD_CMD_READ. The rest of the time it will send back simple replies as before. We do not modify the plugin API so plugins are unable to send complex SRs. Also we do not handle human-readable error m...

On Thu, Apr 12, 2018 at 5:42 PM Eric Blake <eblake@redhat.com> wrote: > On 04/12/2018 05:24 AM, Richard W.M. Jones wrote: > > > I don't think we have nbd-server in RHEL, and in any case wouldn't it > > be better to use qemu-nbd? > > > > You just start a new qemu-nbd process instead of faffing around with > > configuration files, kill the qemu-nbd

On Fri, Aug 14, 2020 at 05:00:25PM -0500, Eric Blake wrote: > diff --git a/lib/internal.h b/lib/internal.h > index 5f495fb..03baacd 100644 > --- a/lib/internal.h > +++ b/lib/internal.h > @@ -101,6 +101,7 @@ struct nbd_handle { > > /* Option negotiation mode. */ > bool opt_mode; > + uint8_t current_opt; Be nice to add a comment here about what current_opt can

v2 was here: https://lists.debian.org/nbd/2022/11/msg00030.html The bulk of the changes since then are: - forbid NBD_OPT_EXPORT_NAME once extended headers are negotiated (Wouter) - consistently use 'maximum payload', rather than a haphazard mix of 'maximum block payload' (Vladimir) At this point, I want to make sure we are happy with the spec before re-posting patches for

I'm hoping to implement .extents for the nbd plugin; this is a prerequisite. I'm not sure about patch 3 - if we like it, I'll squash it to 2, if we don't, I think we are okay just dropping it. I'm also wondering if we have to worry about malicious plugins that don't populate the entire .pread buffer in an effort to get nbdkit to expose portions of the heap; my patch 7 loses

I'm still playing with ideas on how to split rstate from wstate (so that we can send a request without waiting for POLLIN to complete a pending reply), but this is some preliminary refactoring I found useful. I also fixed a couple of bugs while in the area (already pushed). There's a question of whether we want nbd_handle to be nearly 5k, or if we should instead keep it small and add one

Updated based on other changes that have happened in the meantime: - rely more on cleanup.h (throughout) - split structured read for easier review (patch 2 and 3 were combined in v1) - rely on nbdkit not leaking a server's partial answer (patch 3) - add tests (patch 5) - other bug fixes I found while testing it - drop EOVERFLOW patch for now; it will be separate once upstream NBD protocol

On 3/8/19 4:04 AM, Richard W.M. Jones wrote: > This is about the simplest implementation of NBD Structured Replies > (SR) that we can do right now. > > It accepts NBD_OPT_STRUCTURED_REPLIES when negotiated by the client, > but only sends back the simplest possible SR when required to by > NBD_CMD_READ. The rest of the time it will send back simple replies > as before. We do not modify the plugin API so plugins are unable to > send complex SRs. Yep, sounds compliant, a...

Patch 1 played with an early draft of Rich's Fedora 30 libnbd package: https://bugzilla.redhat.com/show_bug.cgi?id=1713767#c17 Note that comment 21 provides a newer package 0.1.1-1 with a different API; and that libnbd has more unreleased API changes in the pipeline (whether that will be called 0.2 or 0.1.2); so we'll have to tweak things based on what is actually available in distros.

This conversion should be feature compatible with the standalone nbd code. Note that the use of libnbd makes the binary for this particular plugin fall under an LGPLv2+ license rather than BSD; but the source code in nbd.c remains BSD. A lot of code simply disappears, now that I'm no longer directly utilizing the NBD protocol files but relying on libnbd. Coordination between threads from

libnbd-0.1.2-1 is now available in Fedora 29/30 updates-testing, although it was not compiled against libxml2 so it lacks uri support (I ended up testing patch 4 with a self-built libnbd). Diffs since v1 - rebase to master, bump from libnbd 0.1 to 0.1.2, add URI support, better timing results Still not done - patch 5 needs associated tests Eric Blake (5): nbd: Check for libnbd nbd:

This conversion should be feature compatible with the standalone nbd code. Note that the use of libnbd makes the binary for this particular plugin fall under an LGPLv2+ license rather than BSD; but the source code in nbd.c remains BSD. A lot of code simply disappears, now that I'm no longer directly utilizing the NBD protocol files but relying on libnbd. Coordination between threads from

When we first used libnbd (nbdkit 1.14), it was brand new, so we left in the ability to build a limited nbd plugin without the use of libnbd for comparison. But now that libnbd has had more time under its belt, and we have learned that our nbd-standalone code is not getting much testing, it's time to follow through with our plan to finish off the old code, and now build the nbd plugin only

The old test relied on issuing an asynchronous command to a qemu-io subprocess, requiring a sleep to ensure that the command had been carried out. ‘sleep 1’ was not long enough on s390x as you can see from this partial trace: + exec + qemu-io -f raw nbd:unix:/tmp/tmp.jqOZGj6dnX + exec + echo 'Reading from connection A, try 1' Reading from connection A, try 1 +

On Thu, Apr 12, 2018 at 2:07 AM Nir Soffer <nirsof@gmail.com> wrote: > On Tue, Apr 10, 2018 at 6:53 PM Richard W.M. Jones <rjones@redhat.com> > wrote: > ... > Dan Berrange pointed out earlier on that it might be easier if imageio >> > just exposed NBD, or if we found a way to tunnel NBD requests over web >> sockets (in the format case nbdkit would not be

libnbd-0.1.4-1 is now available in Fedora 29/30 updates testing. Diffs since v2 - rebase to master, bump from libnbd 0.1.2 to 0.1.3+, add tests to TLS usage which flushed out the need to turn relative pathnames into absolute, doc tweaks Now that the testsuite covers TLS and libnbd has been fixed to provide the things I found lacking when developing v2, I'm leaning towards pushing this on