search for: nbd_enotsup

...e + server MUST set this transmission flag to 1 if the + `NBD_CMD_WRITE_ZEROES` request supports the `NBD_CMD_FLAG_FAST_ZERO` + flag, and MUST set this transmission flag to 0 if + `NBD_FLAG_SEND_WRITE_ZEROES` is not set. Servers MAY set this this + transmission flag even if it will always use `NBD_ENOTSUP` failures for + requests with `NBD_CMD_FLAG_FAST_ZERO` set (such as if the server + cannot quickly determine whether a particular write zeroes request + will be faster than a regular write). Clients MUST NOT set the + `NBD_CMD_FLAG_FAST_ZERO` request flag unless this transmission flag + is set...

...ic Blake <eblake@redhat.com> >> +++ b/nbd/server.c >> @@ -55,6 +55,8 @@ static int system_errno_to_nbd_errno(int err) >> return NBD_ENOSPC; >> case EOVERFLOW: >> return NBD_EOVERFLOW; >> + case ENOTSUP: >> + return NBD_ENOTSUP; > > This may provoke returning NBD_ENOTSUP in other cases, not only new one we are going to add. Correct. But the spec only said SHOULD avoid ENOTSUP in those other cases, not MUST avoid ENOTSUP; and in practice, either the client that is not suspecting it will treat it the same as NBD_EIN...

...still worthwhile; and my cover letter has shown that fast zeroes on their own make a measurable difference to certain workloads. >> + If the server advertised `NBD_FLAG_SEND_FAST_ZERO` but >> + `NBD_CMD_FLAG_FAST_ZERO` is not set, then the server MUST NOT fail >> + with `NBD_ENOTSUP`, even if the operation is no faster than a >> + corresponding `NBD_CMD_WRITE`. Conversely, if >> + `NBD_CMD_FLAG_FAST_ZERO` is set, the server MUST fail quickly with >> + `NBD_ENOTSUP` unless the request can be serviced in less time than >> + a corresponding `NB...

This is a cover letter to a series of patches being proposed in tandem to four different projects: - nbd: Document a new NBD_CMD_FLAG_FAST_ZERO command flag - qemu: Implement the flag for both clients and server - libnbd: Implement the flag for clients - nbdkit: Implement the flag for servers, including the nbd passthrough client If you want to test the patches together, I've pushed a

...(1 << 10) +#define NBD_FLAG_SEND_FAST_ZERO (1 << 11) /* NBD options (new style handshake only). */ #define NBD_OPT_EXPORT_NAME 1 @@ -250,6 +251,7 @@ struct nbd_structured_reply_error { #define NBD_EINVAL 22 #define NBD_ENOSPC 28 #define NBD_EOVERFLOW 75 +#define NBD_ENOTSUP 95 #define NBD_ESHUTDOWN 108 #endif /* NBD_PROTOCOL_H */ diff --git a/generator/generator b/generator/generator index c509573..9b1f5d8 100755 --- a/generator/generator +++ b/generator/generator @@ -958,10 +958,11 @@ let all_enums = [ tls_enum ] let cmd_flags = { flag_prefix = "CMD_FL...

I ran into these while trying to prepare patches to add NBD_CMD_FLAG_FAST_ZERO, which will expose a new NBD_ENOTSUP wire value. Eric Blake (2): plugins: Don't lose original error when emulating FUA plugins: Permit ENOTSUP as synonym for EOPNOTSUPP docs/nbdkit-filter.pod | 11 ++++++----- docs/nbdkit-plugin.pod | 12 +++++++----- plugins/file/file.c | 16 +++++++++++----- plugins/perl/perl.c...

...(1<<4) /* Error codes (previously errno). * See http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ca4414804114fd0095b317785bc0b51862e62ebb @@ -239,6 +241,7 @@ extern const char *name_of_nbd_error (int); #define NBD_EINVAL 22 #define NBD_ENOSPC 28 #define NBD_EOVERFLOW 75 +#define NBD_ENOTSUP 95 #define NBD_ESHUTDOWN 108 #endif /* NBDKIT_PROTOCOL_H */ diff --git a/server/filters.c b/server/filters.c index 14ca0cc6..0dd2393e 100644 --- a/server/filters.c +++ b/server/filters.c @@ -403,8 +403,11 @@ next_zero (void *nxdata, uint32_t count, uint64_t offset, uint32_t flags, int r;...

...col/protocol.h +++ b/common/protocol/nbd-protocol.h @@ -30,8 +30,8 @@ * SUCH DAMAGE. */ -#ifndef NBDKIT_PROTOCOL_H -#define NBDKIT_PROTOCOL_H +#ifndef NBD_PROTOCOL_H +#define NBD_PROTOCOL_H #include <stdint.h> @@ -244,4 +244,4 @@ extern const char *name_of_nbd_error (int); #define NBD_ENOTSUP 95 #define NBD_ESHUTDOWN 108 -#endif /* NBDKIT_PROTOCOL_H */ +#endif /* NBD_PROTOCOL_H */ diff --git a/common/protocol/protostrings.sed b/common/protocol/protostrings.sed index 1731c6b..cb1a76e 100644 --- a/common/protocol/protostrings.sed +++ b/common/protocol/protostrings.sed @@ -29,12 +29,...

...rmissive in what we accept (either spelling, since the two are commonly confused), while strict in what we generate (we documented EOPNOTSUPP as the trigger to fall back to .write, so stick to that internally where it makes sense). An upcoming NBD protocol extension is proposing the exposure of an NBD_ENOTSUP error, and so we'll need to make sure that both errno values (when they are distinct) feed into that single wire value. Signed-off-by: Eric Blake <eblake@redhat.com> --- docs/nbdkit-filter.pod | 11 ++++++----- docs/nbdkit-plugin.pod | 12 +++++++----- plugins/file/file.c | 16 +++...

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

...eplies (via + `NBD_OPT_STRUCTURED_REPLY`) if extended headers have already been + enabled. + ### Transmission phase #### Flag fields @@ -1725,6 +1882,17 @@ valid may depend on negotiation during the handshake phase. `NBD_CMD_WRITE`, then the server MUST fail quickly with an error of `NBD_ENOTSUP`. The client MUST NOT set this unless the server advertised `NBD_FLAG_SEND_FAST_ZERO`. +- bit 5, `NBD_CMD_FLAG_PAYLOAD_LEN`; only valid if extended headers + were negotiated via `NBD_OPT_EXTENDED_HEADERS`. If set, the + *length* field of the header describes a (nonzero) payload length of + d...

We should have only one NBD protocol file. Let's make nbdkit's version the canonical one, and use it in libnbd. Rich.