search for: nbd_opt_

Up to nbdkit 1.22, we never advertised large export lists, so a client had no real reason to give more than 32 NBD_OPT_ commands before finally selecting an export or quitting, and we were justified in dropping indecisive chatty clients as being a waste of server resources. But now that we support .list_exports, it is reasonable for a client (such as 'qemu-nbd --list' or 'nbdinfo --list') to want to...

...r of opt negotiation can be controlled by the caller.  (I >> really need to write a states -> dot graph visualizer!)  When we've >> got to the negotiating state we can then get the list of exports, set >> the export name we want, and then finish the connection with >> nbd_opt_go. > > For now, OPT_STRUCTURED_REPLY is still automatic, although I might > expose it to the user to attempt (I'm certainly thinking about what else > to expose or keep automatic in followup patches; letting the user > control OPT_STARTTLS when tls=1 (but not when tls=0 or tl...

...l and following > (doc: Propose NBD_FLAG_INIT_ZEROES extension) > > > > > I will not push this without both: > > - a positive review (for example, we may decide that burning another > > NBD_FLAG_* is undesirable, and that we should instead have some sort > > of NBD_OPT_ handshake for determining when the server supports > > NBD_CMD_FLAG_FAST_ZERO) >From an implementation point of view I prefer simple flags over having to implement a brand new option. We can always work out how to extend the flags field if we run out of flags. For example, by implementi...

...state transition: Created - Progress only by command issue - namely one of nbd_connect_* Connecting - Progress by aio_notify_read/aio_notify_write (as driven by aio_poll), and progresses through socket establishment and magic numbers Loop of: Negotiating - Progress by command issue (nbd_opt_*) Connecting - Progress by aio_notify_read/aio_notify_write, no commands accepted, and processes remaining handshaking Before getting back to Ready and the normal loop. One thing to remember is that handshaking is always synchronous - the client is not allowed to send the next NBD_OPT_...

...debian.org/nbd/2016/12/msg00015.html and following (doc: Propose NBD_FLAG_INIT_ZEROES extension) > > I will not push this without both: > - a positive review (for example, we may decide that burning another > NBD_FLAG_* is undesirable, and that we should instead have some sort > of NBD_OPT_ handshake for determining when the server supports > NBD_CMF_FLAG_FAST_ZERO) > - a reference client and server implementation (probably both via qemu, > since it was qemu that raised the problem in the first place) The last time we mentioned the possibility of advertising an initial zero...

...uct nbd_handle { > > /* Option negotiation mode. */ > bool opt_mode; > + uint8_t current_opt; Be nice to add a comment here about what current_opt can contain, which would also explain why it has this somewhat unexpected type. Something like: + uint8_t current_opt; /* 0 or NBD_OPT_* */ (Can it only contain NBD_OPT_ABORT or are other options added in later patches?) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports...

...icient, it is better off not advertising NBD_FLAG_SEND_FAST_ZERO. Signed-off-by: Eric Blake <eblake@redhat.com> --- I will not push this without both: - a positive review (for example, we may decide that burning another NBD_FLAG_* is undesirable, and that we should instead have some sort of NBD_OPT_ handshake for determining when the server supports NBD_CMF_FLAG_FAST_ZERO) - a reference client and server implementation (probably both via qemu, since it was qemu that raised the problem in the first place) doc/proto.md | 44 +++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 43 inser...

...onsidered because they are too risky, and run into arbitrary > limits (what escape character to use? what is the max length?) Also > changing the NBD protocol is not under consideration. Not directly, but maybe it is worth adding optional support to the NBD protocol to make it possible for NBD_OPT_LIST to support a hierarchical return. That is, pointing the file plugin to serve directory=base containing the following layout: base + f1 + dir1 + f2 + f3 + dir2 + f4 the current semantics of NBD_OPT_LIST only lend themselves to returning 4 NBD_REP_SERVER replies in a row: &...

...trary limits (what escape character to use? what is the max length?) Also changing the NBD protocol is not under consideration. I think we need to consider these aspects separately: (a) How filters and plugins get the client exportname. (b) How filters and plugins respond when the client issues NBD_OPT_LIST. (c) How the server, filters and plugins respond to NBD_OPT_INFO. (a) Client exportname --------------------- The client sends the export name of the export it wants to access with NBD_OPT_EXPORT_NAME or the newer NBD_OPT_GO. This is an opaque string (not a filename, pathname etc). Curren...

Any server that sends a reply to NBD_OPT_* or NBD_CMD_* longer than the maximum length we are willing to use for NBD_CMD_{READ,WRITE} is probably broken; it is not worth waiting for read() to wait for that many bytes to arrive from the server to bring the connection back into sync for the next operation, so just declare it dead. It may be...

...) to kick it off immediately; or is masked (in a processing state) to queue things but leave the interrupt set (the next time we enter READY, we unmask, observe the queue is non-empty, and so fire off the next command). Another thought - if we ever want to allow the user the ability to send custom NBD_OPT_ commands during handshake, or even to emulate 'qemu-nbd --list' where the client can make queries to see what the server supports before finally settling on whether to run NBD_OPT_GO or NBD_OPT_ABORT, we'll need to add an external event after nbd_aio_connect but before nbd_aio_is_connec...

...D_NEW_VERSION UINT64_C(0x49484156454F5054) /* ASCII "IHAVEOPT" */ /* New-style handshake option (sent by the client to us). */ struct nbd_new_option { - uint64_t version; /* NEW_VERSION */ + uint64_t version; /* NBD_NEW_VERSION */ uint32_t option; /* NBD_OPT_* */ uint32_t optlen; /* option data length */ /* option data follows */ } NBD_ATTRIBUTE_PACKED; -/* Newstyle handshake OPT_EXPORT_NAME reply message. */ +/* Newstyle handshake OPT_EXPORT_NAME reply message. + * Modern clients use NBD_OPT_GO instead of this. + */ struct nbd_expor...

...uld need to do some massaging on this to get it into the right format for NBD_CMD_BLOCK_STATUS. (I'm very confused about what NBD_CMD_FLAG_REQ_ONE is supposed to do.) We will also need a corresponding ‘can_extents’, which is analogous to ‘can_write’ etc and is what would control the output of NBD_OPT_{SET,LIST}_META_CONTEXT. For nbdkit-file-filter: - Fairly simple implementation using SEEK_HOLE/SEEK_DATA. - Not sure how we detect zeroes without reading the file. For nbdkit-memory-plugin: - Pretty simple implementation, which can even detect non-hole zeroes. For VDDK: - VixDiskLib_QueryA...

On Tue, Jan 24, 2017 at 10:36:43AM -0600, Eric Blake wrote: > On 01/24/2017 09:41 AM, Richard W.M. Jones wrote: > > On Tue, Jan 24, 2017 at 03:16:45PM +0000, Richard W.M. Jones wrote: > >> However we could add another API: > >> > >> nbdkit_set_errno (int errno); > >> > >> This allows the plugin to send the errno back to the core code >

...> https://lists.debian.org/nbd/2019/03/msg00004.html > where I stated: > > > I will not push this without both: > > - a positive review (for example, we may decide that burning another > > NBD_FLAG_* is undesirable, and that we should instead have some sort > > of NBD_OPT_ handshake for determining when the server supports > > NBD_CMF_FLAG_FAST_ZERO) > > - a reference client and server implementation (probably both via qemu, > > since it was qemu that raised the problem in the first place) Is the plan to wait until NBD_CMF_FLAG_FAST_ZERO gets into...

...uot; */ uint64_t version; /* NBD_NEW_VERSION */ uint16_t gflags; /* global flags */ -} __attribute__((packed)); +} NBD_ATTRIBUTE_PACKED; #define NBD_NEW_VERSION UINT64_C(0x49484156454F5054) @@ -69,14 +75,14 @@ struct nbd_new_option { uint32_t option; /* NBD_OPT_* */ uint32_t optlen; /* option data length */ /* option data follows */ -} __attribute__((packed)); +} NBD_ATTRIBUTE_PACKED; /* Newstyle handshake OPT_EXPORT_NAME reply message. */ struct nbd_export_name_option_reply { uint64_t exportsize; /* size of export */ ui...

If a plugin's .open or .get_size or .can_write fails, right now that is fatal to the connection. When nbdkit was first implemented, this made sense (there was no way to report errors to oldstyle or NBD_OPT_EXPORT_NAME). But now that newstyle is around, it's rather abrupt to hang up on the client, and better is to return an error to NBD_OPT_GO, and let the client choose what to do (most clients will probably hang up, whether gracefully with NBD_OPT_ABORT or abruptly, rather than try other NBD_OPT_...

More nbd-protocol.h improvements Eric Blake (2): common/protocol: Switch nbdmagic to uint64_t common/protocol: Declare additional constants common/protocol/nbd-protocol.h | 16 ++++++++++------ server/protocol-handshake-newstyle.c | 2 +- server/protocol-handshake-oldstyle.c | 2 +- plugins/nbd/nbd-standalone.c | 2 +- tests/test-layers.c | 2 +- 5 files

It is finally time to introduce our first negotiating option command. With this change, we can now enter NEWSTYLE.START more than once; as such, it needs to know whether it is the first entry (proceed with gflags/cflags, TLS, and structured reply) or a later entry (all nbd_opt_* will cause an IssueCommand event to kick the state machine out of NEGOTIATING, at which point we want to jump to the sub-state appropriate for that option). This is done by setting h->current_opt prior to entering NEWSTYLE. We also need a couple of new states to implement NBD_OPT_ABORT; this...

...e is only sent once. CmdConnect* are only sent once. CmdIssue can be sent multiple times but commands are queued so as long as the writer side always checks the issue queue at appropriate points we're OK. > Another thought - if we ever want to allow the user the ability to send > custom NBD_OPT_ commands during handshake, or even to emulate 'qemu-nbd > --list' where the client can make queries to see what the server > supports before finally settling on whether to run NBD_OPT_GO or > NBD_OPT_ABORT, we'll need to add an external event after nbd_aio_connect > but befo...