search for: nbd_info_block_size

...y possible request. But such a wrapper should only be synchronous and not copied to nbd_aio_*, because getting locking right is a bear if you have two non-overlapping client requests that want to visit the same larger-granularity window of the server in parallel. Eric Blake (3): states: Request NBD_INFO_BLOCK_SIZE during NBD_OPT_GO api: Add new API to query negotiated block size nbdinfo: Expose block size constraints info/nbdinfo.pod | 6 +++ lib/internal.h | 7 +++ lib/nbd-protocol.h | 10 ++++- generator/API.ml | 70 +++++++++++...

I'm thinking of adding one or more callbacks to nbdkit to let plugins/filters enforce various block size alignments (for example, the swab filter requires 2/4/8 alignment, or VDDK requires 512 alignment, etc). The NBD protocol currently has NBD_INFO_BLOCK_SIZE which can be sent in reply to NBD_OPT_GO to tell the client about sizing constraints; qemu already implements it as both client and server, so we have some reasonable testing setups (although libnbd will also need some additions to make it easier to expose constraints to the user, and/or add ne...

...:54:31AM -0500, Eric Blake wrote: > I'm thinking of adding one or more callbacks to nbdkit to let > plugins/filters enforce various block size alignments (for example, > the swab filter requires 2/4/8 alignment, or VDDK requires 512 > alignment, etc). The NBD protocol currently has NBD_INFO_BLOCK_SIZE > which can be sent in reply to NBD_OPT_GO to tell the client about > sizing constraints; qemu already implements it as both client and > server, so we have some reasonable testing setups (although libnbd > will also need some additions to make it easier to expose > constraints to th...

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

...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(-) diff --git a/doc/proto.md b/doc/proto.md index ddf0a89..9fa471a 100644 --- a/doc/proto.md +++ b/doc/proto.md @@ -2024,18...

...block size constraints defined here (minimum, > -preferred, and maximum). > +as well as by three block size constraints defined here (minimum > +block, preferred block, and maximum payload). > > If a client can honour server block size constraints (as set out below > and under `NBD_INFO_BLOCK_SIZE`), it SHOULD announce this during the > @@ -772,15 +772,15 @@ learn the server's constraints without committing to them. > > If block size constraints have not been advertised or agreed on > externally, then a server SHOULD support a default minimum block size > -of 1, a prefe...

...has not indicated extension suppport for payloads on that +command. A server SHOULD initiate hard disconnect if a client sets +the `NBD_CMD_FLAG_PAYLOAD_LEN` flag and uses a *length* larger than +a server's advertised or default maximum payload length (capped at +32 bits by the constraints of `NBD_INFO_BLOCK_SIZE`); in all other +cases, a server SHOULD gracefully consume *length* bytes of payload +(even if it then replies with an `NBD_EINVAL` failure because the +particular command was not expecting a payload), and proceed with +the next client command. Thus, only when *length* is used as an +effective len...

...lt; 1) /* Per-export flags. */ #define NBD_FLAG_HAS_FLAGS (1 << 0) @@ -143,6 +143,9 @@ struct nbd_fixed_new_option_reply { #define NBD_REP_ERR_TOO_BIG NBD_REP_ERR (9) #define NBD_INFO_EXPORT 0 +#define NBD_INFO_NAME 1 +#define NBD_INFO_DESCRIPTION 2 +#define NBD_INFO_BLOCK_SIZE 3 /* NBD_INFO_EXPORT reply (follows fixed_new_option_reply). */ struct nbd_fixed_new_option_reply_info_export { -- 2.21.0

...here (minimum, > > -preferred, and maximum). > > +as well as by three block size constraints defined here (minimum > > +block, preferred block, and maximum payload). > > > > If a client can honour server block size constraints (as set out below > > and under `NBD_INFO_BLOCK_SIZE`), it SHOULD announce this during the > > @@ -772,15 +772,15 @@ learn the server's constraints without committing to them. > > > > If block size constraints have not been advertised or agreed on > > externally, then a server SHOULD support a default minimum block size...

...lt; 1) /* Per-export flags. */ #define NBD_FLAG_HAS_FLAGS (1 << 0) @@ -140,6 +143,9 @@ struct nbd_fixed_new_option_reply { #define NBD_REP_ERR_TOO_BIG NBD_REP_ERR (9) #define NBD_INFO_EXPORT 0 +#define NBD_INFO_NAME 1 +#define NBD_INFO_DESCRIPTION 2 +#define NBD_INFO_BLOCK_SIZE 3 /* NBD_INFO_EXPORT reply (follows fixed_new_option_reply). */ struct nbd_fixed_new_option_reply_info_export { @@ -160,15 +166,6 @@ struct nbd_block_descriptor { uint32_t status_flags; /* block type (hole etc) */ } NBD_ATTRIBUTE_PACKED; -/* New-style handshake server reply when usi...

...XT_STATE (%.DEAD); + set_error (0, "handshake: incorrect NBD_INFO_INIT_STATE option reply length"); + return 0; + } + h->initflags = be16toh (h->sbuf.or.payload.init.flags); + break; default: /* XXX Handle other info types, like NBD_INFO_BLOCK_SIZE */ debug (h, "skipping unknown NBD_REP_INFO type %d", diff --git a/interop/Makefile.am b/interop/Makefile.am index 345be7c..ed5b553 100644 --- a/interop/Makefile.am +++ b/interop/Makefile.am @@ -1,5 +1,5 @@ # nbd client library in userspace -# Copyright (C) 2013-2019 Red Hat Inc...

...ff --git a/TODO b/TODO index 239e0b0..4a0cd22 100644 --- a/TODO +++ b/TODO @@ -9,12 +9,8 @@ Example code integrating with ppoll, pollfd, APR pollset (and others?). Example command line utils to copy in/out (like qemu-img convert). -NBD_OPT_INFO mode (like qemu-nbd -L). - NBD resize extension. -NBD_INFO_BLOCK_SIZE. - TLS should properly shut down the session (calling gnutls_bye). Performance: Chart it over various buffer sizes and threads, as that @@ -71,12 +67,3 @@ Suggested API improvements: maybe nbd_shutdown should wait for the subprocess or there should be another API to do this - captur...

...p-nbdkit-tls-psk +/interop/interop-nbdkit-tls-psk-allow-enabled +/interop/interop-nbdkit-tls-psk-allow-fallback /interop/interop-nbd-server /interop/interop-qemu-nbd /interop/interop-qemu-nbd-tls-certs diff --git a/TODO b/TODO index 21feb2f..642d39f 100644 --- a/TODO +++ b/TODO @@ -17,9 +17,6 @@ NBD_INFO_BLOCK_SIZE. TLS should properly shut down the session (calling gnutls_bye). -LIBNBD_TLS_ALLOW is not tested. Related to this, -nbd_get_tls_negotiated is not tested. - Implement nbd_connect + systemd socket activation. Improve function trace output so that: diff --git a/interop/Makefile.am b/interop/...

On Wed, Feb 12, 2020 at 06:09:11AM -0600, Eric Blake wrote: > On 2/12/20 1:27 AM, Wouter Verhelst wrote: > >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

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

...e_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 fixed_new_option_reply_info_export reply_export; + char *buffer; + uint16_t info; + + /* TODO: structured reads, block status */ + + /* Try NBD_OPT_GO */ + nbdkit_deb...

Although the time spent in memcpy/memset probably pales in comparison to time spent in socket I/O, it's still worth worth reducing the number of times we have to utilize a bounce buffer when we already have aligned data. Signed-off-by: Eric Blake <eblake@redhat.com> --- filters/cache/cache.c | 60 ++++++++++++++++++++++++++++--------------- 1 file changed, 39 insertions(+), 21

As the subject says, how close are we to being able to declare a stable API for libnbd? I believe these are the main topics: * Do we need to have an extra thread for writing? I'm unclear about whether b92392b717 (which allows the state machine to break during reply processing) means we definitely don't need threads. I imagine that two threads doing simultaneous send(2) and

.../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 nbdkit: sh[1]: debug: completed...

...nsmission headers will be used. > > + > > + Note that a response of `NBD_REP_ERR_BLOCK_SIZE_REQD` does not > > + make sense in response to this command, but a server MAY fail with > > + that error for a later `NBD_OPT_GO` without a client request for > > + `NBD_INFO_BLOCK_SIZE`, since the use of extended headers provides > > + more incentive for a client to promise to obey block size > > + constraints. > > + > > + If the client requests `NBD_OPT_STARTTLS` after this option, it > > + MUST renegotiate extended headers. > > +...