search for: nbd_cmd_flag_df

...t;< 8) > > /* NBD options (new style handshake only). */ > @@ -217,6 +218,7 @@ extern const char *name_of_nbd_cmd (int); > extern const char *name_of_nbd_cmd_flag (int); > #define NBD_CMD_FLAG_FUA (1<<0) > #define NBD_CMD_FLAG_NO_HOLE (1<<1) > +#define NBD_CMD_FLAG_DF (1<<2) > #define NBD_CMD_FLAG_REQ_ONE (1<<3) > > /* Error codes (previously errno). > diff --git a/server/protocol-handshake.c b/server/protocol-handshake.c > index 9653210..f0e5a2c 100644 > --- a/server/protocol-handshake.c > +++ b/server/protocol-handsha...

...ne NBD_FLAG_CAN_MULTI_CONN (1 << 8) /* NBD options (new style handshake only). */ @@ -217,6 +218,7 @@ extern const char *name_of_nbd_cmd (int); extern const char *name_of_nbd_cmd_flag (int); #define NBD_CMD_FLAG_FUA (1<<0) #define NBD_CMD_FLAG_NO_HOLE (1<<1) +#define NBD_CMD_FLAG_DF (1<<2) #define NBD_CMD_FLAG_REQ_ONE (1<<3) /* Error codes (previously errno). diff --git a/server/protocol-handshake.c b/server/protocol-handshake.c index 9653210..f0e5a2c 100644 --- a/server/protocol-handshake.c +++ b/server/protocol-handshake.c @@ -121,6 +121,9 @@ protocol_c...

On 4/1/19 10:09 AM, Martin Kletzander wrote: >>> +++ b/TODO >>> @@ -24,8 +24,8 @@ General ideas for improvements >>>    to inform nbdkit when the response is ready: >>>    https://www.redhat.com/archives/libguestfs/2018-January/msg00149.html >>> >>> -* More NBD protocol features.  The only currently missing feature is >>> -  online

.../* NBD options (new style handshake only). */ >> @@ -217,6 +218,7 @@ extern const char *name_of_nbd_cmd (int); >> extern const char *name_of_nbd_cmd_flag (int); >> #define NBD_CMD_FLAG_FUA (1<<0) >> #define NBD_CMD_FLAG_NO_HOLE (1<<1) >> +#define NBD_CMD_FLAG_DF (1<<2) >> #define NBD_CMD_FLAG_REQ_ONE (1<<3) >> >> /* Error codes (previously errno). >> diff --git a/server/protocol-handshake.c b/server/protocol-handshake.c >> index 9653210..f0e5a2c 100644 >> --- a/server/protocol-handshake.c >> ++...

...;write_lock); > struct structured_reply reply; > @@ -593,7 +596,7 @@ send_structured_reply_error (struct connection *conn, > } > > /* Send the error. */ > - error_data.error = htobe32 (nbd_errno (error)); > + error_data.error = htobe32 (nbd_errno (error, flags & NBD_CMD_FLAG_DF)); > error_data.len = htobe16 (0); > r = conn->send (conn, &error_data, sizeof error_data); > if (r == -1) { > @@ -737,7 +740,8 @@ protocol_recv_request_send_reply (struct connection *conn) > extents); > } &g...

On Fri, Mar 08, 2019 at 09:03:05AM -0600, Eric Blake wrote: > On 3/8/19 4:04 AM, Richard W.M. Jones wrote: > > Also we do not understand NBD_CMD_FLAG_DF, but that seems to be OK > > because (a) we don't advertize the feature and (b) we only send back a > > single chunk anyway. > > Or, we COULD advertise it because we always honor it (but that's a > larger diffstat, and thus at odds with "minimal implementation&quo...

...only). */ extern const char *name_of_nbd_opt (int); @@ -223,10 +224,11 @@ extern const char *name_of_nbd_cmd (int); #define NBD_CMD_BLOCK_STATUS 7 extern const char *name_of_nbd_cmd_flag (int); -#define NBD_CMD_FLAG_FUA (1<<0) -#define NBD_CMD_FLAG_NO_HOLE (1<<1) -#define NBD_CMD_FLAG_DF (1<<2) -#define NBD_CMD_FLAG_REQ_ONE (1<<3) +#define NBD_CMD_FLAG_FUA (1<<0) +#define NBD_CMD_FLAG_NO_HOLE (1<<1) +#define NBD_CMD_FLAG_DF (1<<2) +#define NBD_CMD_FLAG_REQ_ONE (1<<3) +#define NBD_CMD_FLAG_FAST_ZERO (1<<4) /* Error...

...239,12 +239,11 @@ struct nbd_structured_reply_error { #define NBD_CMD_WRITE_ZEROES 6 #define NBD_CMD_BLOCK_STATUS 7 -/* Command flags. Exposed by the generator as LIBNBD_CMD_FLAG_* instead -#define NBD_CMD_FLAG_FUA (1<<0) -#define NBD_CMD_FLAG_NO_HOLE (1<<1) -#define NBD_CMD_FLAG_DF (1<<2) -#define NBD_CMD_FLAG_REQ_ONE (1<<3) -*/ +#define NBD_CMD_FLAG_FUA (1<<0) +#define NBD_CMD_FLAG_NO_HOLE (1<<1) +#define NBD_CMD_FLAG_DF (1<<2) +#define NBD_CMD_FLAG_REQ_ONE (1<<3) +#define NBD_CMD_FLAG_FAST_ZERO (1<<4) /* N...

...7ff2e45e (Apr 2016) promoted structured > replies to be part of the protocol, so any client that negotiates > structured replies is thus new enough to expect EOVERFLOW; conversely, > EOVERFLOW is only documented as being reasonable for the server to send > in response to a client using NBD_CMD_FLAG_DF to NBD_CMD_READ (again, > which implies the client negotiated structured replies), and not all > clients support structured replies. OTOH, for backcompat reasons it is reasonable to state that older versions of nbd-server could send pretty much anything over the wire[1], and that clients sho...

...ent as zero bytes */ > -} __attribute__((packed)); > +} NBD_ATTRIBUTE_PACKED; Redundant type. > > -/* Command flags. Exposed by the generator as LIBNBD_CMD_FLAG_* instead > -#define NBD_CMD_FLAG_FUA (1<<0) > -#define NBD_CMD_FLAG_NO_HOLE (1<<1) > -#define NBD_CMD_FLAG_DF (1<<2) > -#define NBD_CMD_FLAG_REQ_ONE (1<<3) > -*/ > +#define NBD_CMD_FLAG_FUA (1<<0) > +#define NBD_CMD_FLAG_NO_HOLE (1<<1) > +#define NBD_CMD_FLAG_DF (1<<2) > +#define NBD_CMD_FLAG_REQ_ONE (1<<3) > +#define NBD_CMD_...

...or value when commit 7ff2e45e (Apr 2016) promoted structured replies to be part of the protocol, so any client that negotiates structured replies is thus new enough to expect EOVERFLOW; conversely, EOVERFLOW is only documented as being reasonable for the server to send in response to a client using NBD_CMD_FLAG_DF to NBD_CMD_READ (again, which implies the client negotiated structured replies), and not all clients support structured replies. See also my recent thread about the potential of adding ENOTSUP as a valid error, towards the end of the message: https://lists.debian.org/nbd/2019/03/msg00007.html The...

...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 messages yet because that would require changes in how we handle nbdkit_error(). Also we do not understand NBD_CMD_FLAG_DF, but that seems to be OK because (a) we don't advertize the feature and (b) we only send back a single chunk anyway. --- docs/nbdkit-protocol.pod | 6 +- server/protocol.h | 59 +++++++++--- plugins/nbd/nbd.c | 4 +- server/connections.c | 189 +++++++++++++++++++++++++++...

...CK_FOR_CURRENT_SCOPE (&conn->write_lock); struct structured_reply reply; @@ -593,7 +596,7 @@ send_structured_reply_error (struct connection *conn, } /* Send the error. */ - error_data.error = htobe32 (nbd_errno (error)); + error_data.error = htobe32 (nbd_errno (error, flags & NBD_CMD_FLAG_DF)); error_data.len = htobe16 (0); r = conn->send (conn, &error_data, sizeof error_data); if (r == -1) { @@ -737,7 +740,8 @@ protocol_recv_request_send_reply (struct connection *conn) extents); } else - return send_str...

...hat is not suspecting it will treat it the same as NBD_EINVAL, or we've managed to get a slightly better error message across than normal. I don't see that as a real show-stopper. But if it bothers you, note that in nbdkit, I actually coded things up to refuse to send NBD_EOVERFLOW unless NBD_CMD_FLAG_DF was set, and to refuse to send NBD_ENOTSUP unless NBD_CMD_FLAG_FAST_ZERO was set. I could copy that behavior here, if we want qemu to be that much stricter as a server. (Note to self: also check if, when using structured replies to send error messages, in addition to the code, if the string contai...

...MD_BLOCK_STATUS has been implemented allowing clients to query which parts of the disk are allocated, holes or zeroes. Plugins and filters have been extended to supply this information in many cases. This required adding minimal support for NBD protocol Structured Replies, NBD_CMD_FLAG_REQ_ONE and NBD_CMD_FLAG_DF. (Thanks to Eric Blake for extensive help with this one.) The line "All rights reserved." was removed from the license with agreement from all contributors. Note this does not change the license. nbdkit_error errors are printed in red when writing to the terminal, making them much eas...

.... I'll read through this one in detail, but interoperability with qemu is already a good sign that it's workable. > > Also we do not handle human-readable error messages yet because that > would require changes in how we handle nbdkit_error(). > > Also we do not understand NBD_CMD_FLAG_DF, but that seems to be OK > because (a) we don't advertize the feature and (b) we only send back a > single chunk anyway. Or, we COULD advertise it because we always honor it (but that's a larger diffstat, and thus at odds with "minimal implementation"). Either way works....

...MD_BLOCK_STATUS has been implemented allowing clients to query which parts of the disk are allocated, holes or zeroes. Plugins and filters have been extended to supply this information in many cases. This required adding minimal support for NBD protocol Structured Replies, NBD_CMD_FLAG_REQ_ONE and NBD_CMD_FLAG_DF. (Thanks to Eric Blake for extensive help with this one.) The ‘vddk’ plugin has been updated to VDDK 6.7, but now also works back as far as VDDK 5.1.1. It supports extents, flush and FUA. Also added: new flags single-link and unbuffered. (Thanks to Martin Kletzander). The line "All right...

...-238,10 +239,12 @@ struct nbd_structured_reply_error { #define NBD_CMD_WRITE_ZEROES 6 #define NBD_CMD_BLOCK_STATUS 7 +/* Command flags. Exposed by the generator as LIBNBD_CMD_FLAG_* instead #define NBD_CMD_FLAG_FUA (1<<0) #define NBD_CMD_FLAG_NO_HOLE (1<<1) #define NBD_CMD_FLAG_DF (1<<2) #define NBD_CMD_FLAG_REQ_ONE (1<<3) +*/ /* NBD error codes. */ #define NBD_SUCCESS 0 diff --git a/generator/generator b/generator/generator index a72f36c..170121e 100755 --- a/generator/generator +++ b/generator/generator @@ -971,7 +971,14 @@ let cmd_flags = {...

...t for `NBD_CMD_TRIM`. - bit 6, `NBD_FLAG_SEND_WRITE_ZEROES`: exposes support for `NBD_CMD_WRITE_ZEROES` and `NBD_CMD_FLAG_NO_HOLE`. -- bit 7, `NBD_FLAG_SEND_DF`: do not fragment a structured reply. The - server MUST set this transmission flag to 1 if the - `NBD_CMD_READ` request supports the `NBD_CMD_FLAG_DF` flag, and - MUST leave this flag clear if structured replies have not been - negotiated. Clients MUST NOT set the `NBD_CMD_FLAG_DF` request - flag unless this transmission flag is set. +- bit 7, `NBD_FLAG_SEND_DF`: do not fragment a structured or extended + reply. The server MUST set this tran...

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