search for: nbd_info_

...debug ("newstyle negotiation: %s: " "client requested export '%s' (ignored)", - requested_exportname); + optname, requested_exportname); /* The spec is confusing, but it is required that we send back * NBD_INFO_EXPORT, even if the client did not request it! @@ -855,8 +858,8 @@ _negotiate_handshake_newstyle_options (struct connection *conn) switch (info) { case NBD_INFO_EXPORT: /* ignore - reply sent above */ break; default: - debug ("newstyle negotiation: NB...

...image reads as zero), and save any future bits for later > additions. Do we think that 16 bits is sufficient for the amount of > initial information likely to be exposed? So as I understand the proposal, the 16 bit limit comes about because we want a round 4 byte reply, 16 bits are used by NBD_INFO_INIT_STATE and that leaves 16 bits feature bits. Therefore the only way to go from there is to have 32 feature bits but an awkward unaligned 6 byte structure, or 48 feature bits (8 byte structure). I guess given those constraints we can stick with 16 feature bits, and if we ever needed more then w...

Hi, On Mon, Feb 10, 2020 at 10:52:55PM +0000, Richard W.M. Jones wrote: > But anyway ... could a flag indicating that the whole image is sparse > be useful, either as well as NBD_INIT_SPARSE or instead of it? You > could use it to avoid an initial disk trim, which is something that > mke2fs does: Yeah, I think that could definitely be useful. I honestly can't see a use for

...IT_SPARSE (entire image is sparse, nothing is allocated) and NBD_INIT_ZERO (entire image reads as zero), and save any future bits for later additions. Do we think that 16 bits is sufficient for the amount of initial information likely to be exposed? Are we in agreement that my addition of an NBD_INFO_ response to NBD_OPT_GO is the best way to expose initial state bits? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org

...uld combine requests in flight so that a write-zero (offset) followed by a write-data (same offset) would erase the earlier request. In some circumstances that might provide a performance improvement without needing any changes to protocols. > - NBD should have a way to advertise (probably via NBD_INFO_ during > NBD_OPT_GO) if the initial image is known to begin life with all zeroes > (if that is the case, qemu-img can skip the extents calls and > pre-zeroing pass altogether) Yes, I really think we should do this one as well. Rich. -- Richard Jones, Virtualization Group, Red Hat http:...

There's no substantial difference over v1, I simply fixed a few whitespace issues, moved one struct around and tidied up the comments. Rich.

With some crufty sed scripts we can generate functions that map from NBD protocol flags (eg. NBD_CMD_READ) to strings ("NBD_CMD_READ"). This works on GNU sed and with FreeBSD, also with GNU sed's --posix option, so I guess the sed code is POSIX-compatible. Rich.

...ess testing, I have separated it into a separate optional patch. I implemented it in my proof-of-concept, but am happy to drop this patch for what actually goes upstream. In particular, if we foresee clients and servers that WANT to support a payload larger than 4G, it may be worth introducing an NBD_INFO_* that supplies 64-bit block sizing information, rather than our current inherent 32-bit limit of NBD_INFO_BLOCK_SIZE, at the same time as we introduce this reply type. --- doc/proto.md | 73 ++++++++++++++++++++++++++++++---------------------- 1 file changed, 42 insertions(+), 31 deletions(-) dif...

.... + Return 1 if haggling completed, 0 if haggling failed but + NBD_OPT_EXPORT_NAME is still viable, or -1 on inability to connect. */ +static int +nbd_newstyle_haggle (struct handle *h) +{ + struct new_option opt; + uint32_t exportnamelen = htobe32 (strlen (export)); + /* For now, we make no NBD_INFO_* requests, relying on the server to + send its defaults. TODO: nbdkit should let plugins report block + sizes, at which point we should request NBD_INFO_BLOCK_SIZE and + obey any sizes set by server. */ + uint16_t nrinfos = htobe16 (0); + struct fixed_new_option_reply reply; + struct...

...name[exportnamelen] = '\0'; + debug ("newstyle negotiation: NBD_OPT_GO: " + "client requested export '%s' (ignored)", + requested_exportname); + + /* The spec is confusing, but it is required that we send back + * NBD_INFO_EXPORT, even if the client did not request it! + * qemu client in particular does not request this, but will + * fail if we don't send it. + */ + if (get_size_and_eflags (conn) == -1) + return -1; + if (send_newstyle_option_reply_info_export (conn,...

The NBD spec says that additional information in response to NBD_OPT_GO or NBD_OPT_INFO, such as NBD_INFO_NAME, is optional, but also recommends that if a client hints about wanting a particular piece of information, that it is better for the server to reply to those known hints. This is also the the only way for a client to learn the canonical name that is used when connecting to the default export na...

...kit: file[1]: debug: can_write nbdkit: file[1]: debug: can_trim nbdkit: file[1]: debug: can_fua nbdkit: file[1]: debug: can_flush nbdkit: file[1]: debug: is_rotational nbdkit: file[1]: debug: newstyle negotiation: flags: export 0x6d nbdkit: file[1]: debug: newstyle negotiation: NBD_OPT_GO: ignoring NBD_INFO_* request 3 nbdkit: file[1]: debug: handshake complete, processing requests with 16 threads nbdkit: debug: starting worker thread file.0 nbdkit: debug: starting worker thread file.1 nbdkit: debug: starting worker thread file.3 nbdkit: debug: starting worker thread file.2 nbdkit: debug: starting work...

...h[1]: debug: calling: /tmp/nbdkitpKY00D/inline-script.sh can_extents "" nbdkit: sh[1]: debug: completed: /tmp/nbdkitpKY00D/inline-script.sh can_extents: status 2 nbdkit: sh[1]: debug: newstyle negotiation: flags: export 0x83 nbdkit: sh[1]: debug: newstyle negotiation: NBD_OPT_GO: ignoring NBD_INFO_* request 3 (NBD_INFO_BLOCK_SIZE) nbdkit: sh[1]: debug: handshake complete, processing requests serially nbdkit: sh[1]: debug: retry: pread count=512 offset=0 nbdkit: sh[1]: debug: sh: pread count=512 offset=0 nbdkit: sh[1]: debug: calling: /tmp/nbdkitpKY00D/inline-script.sh pread "" 512 0...

This is only lightly tested (against just qemu NBD client), and the code might be structured a little better as the _negotiate_handshake_newstyle_options function has now grown to be huge. Anyway works for me. Rich.

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

...lling: /tmp/nbdkitpKY00D/inline-script.sh can_extents "" > nbdkit: sh[1]: debug: completed: /tmp/nbdkitpKY00D/inline-script.sh can_extents: status 2 > nbdkit: sh[1]: debug: newstyle negotiation: flags: export 0x83 > nbdkit: sh[1]: debug: newstyle negotiation: NBD_OPT_GO: ignoring NBD_INFO_* request 3 (NBD_INFO_BLOCK_SIZE) > nbdkit: sh[1]: debug: handshake complete, processing requests serially > nbdkit: sh[1]: debug: retry: pread count=512 offset=0 > nbdkit: sh[1]: debug: sh: pread count=512 offset=0 > nbdkit: sh[1]: debug: calling: /tmp/nbdkitpKY00D/inline-script.sh prea...

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 about to add an 'exportname' filter, and in the process, I noticed a few shortcomings in our API. Having .default_export makes it easy to answer NBD_INFO_NAME in response to a client request during NBD_OPT_GO, but answering NBD_INFO_DESCRIPTION is awkward - there's no guarantee the export name was given with a description in .list_exports. Note, however, that while we map "" into a canonical name prior to .open (as the plugin is easier...

...ame[exportnamelen] = '\0'; - debug ("newstyle negotiation: %s: " - "client requested export '%s' (ignored)", - optname, requested_exportname); - - /* The spec is confusing, but it is required that we send back - * NBD_INFO_EXPORT, even if the client did not request it! - * qemu client in particular does not request this, but will - * fail if we don't send it. - */ - if (finish_newstyle_options (conn) == -1) - return -1; - - if (send_newstyle_option_reply_info_export (...

These are a couple of patches in preparation for the Block Status implementation. While the patches (especially the second one) are very large they are really just elementary code motion. Rich.