search for: nbd_block_status

...ock status to the NBD server"; longdesc = "\ diff --git a/interop/dirty-bitmap.c b/interop/dirty-bitmap.c index 0a808b2..e096868 100644 --- a/interop/dirty-bitmap.c +++ b/interop/dirty-bitmap.c @@ -106,13 +106,13 @@ main (int argc, char *argv[]) exit (EXIT_FAILURE); } - if (nbd_block_status (nbd, exportsize, 0, 0, NULL, cb) == -1) { + if (nbd_block_status (nbd, exportsize, 0, NULL, cb, 0) == -1) { fprintf (stderr, "%s\n", nbd_get_error ()); exit (EXIT_FAILURE); } assert (calls == 0x11); - if (nbd_block_status (nbd, exportsize, 0, LIBNBD_CMD_FLAG_REQ_ONE, -...

...ort for NBD URLs which is going on upstream. > > That needs to be fixed, but in the meantime just use $unixsocket > instead (see nbdkit-captive(1) man page for the full details). In the meantime, I don't mind working on the quick fix for rejecting an invalid URI. > >> When nbd_block_status() callback returns -1, the nbd_block_status() function >> reports: >> >> command failed: Protocol error (errno = 71) >> >> which is a bit confusing to me. I could be nicer to have that report that it >> really was the callback that caused this. > > Not s...

...socket. When this string is passed to nbd_connect_uri(), it does not return an error (even though it is not a valid URL), but what's more it treats it as "nbd://localhost", which might be a completely different server (that actually happened to me and it was kind of confusing). When nbd_block_status() callback returns -1, the nbd_block_status() function reports: command failed: Protocol error (errno = 71) which is a bit confusing to me. I could be nicer to have that report that it really was the callback that caused this. One last thing is that I could not find any definition for the fla...

..._data);\n" name ); let errcode = diff --git a/interop/dirty-bitmap.c b/interop/dirty-bitmap.c index 6b7493e..8f0087d 100644 --- a/interop/dirty-bitmap.c +++ b/interop/dirty-bitmap.c @@ -137,14 +137,14 @@ main (int argc, char *argv[]) } data = (struct data) { .count = 2, }; - if (nbd_block_status (nbd, exportsize, 0, &data, cb, 0) == -1) { + if (nbd_block_status (nbd, exportsize, 0, cb, &data, 0) == -1) { fprintf (stderr, "%s\n", nbd_get_error ()); exit (EXIT_FAILURE); } assert (data.seen_base && data.seen_dirty); data = (struct data) { .req_on...

...E_MINIMUM) ?: 512; + max_len = UINT32_MAX - align + 1; size = nbd_get_size (nbd); if (size == -1) { @@ -286,7 +290,7 @@ main (int argc, char *argv[]) if (json_output) fprintf (fp, "[\n"); for (offset = 0; offset < size;) { prev_offset = offset; - if (nbd_block_status (nbd, size - offset, offset, + if (nbd_block_status (nbd, MIN (size - offset, max_len), offset, (nbd_extent_callback) { .callback = extent_callback, .user_data = &offset }, 0) ==...

...gt;> >> That needs to be fixed, but in the meantime just use $unixsocket >> instead (see nbdkit-captive(1) man page for the full details). > > In the meantime, I don't mind working on the quick fix for rejecting an > invalid URI. Done. > >> >>> When nbd_block_status() callback returns -1, the nbd_block_status() function >>> reports: >>> >>> command failed: Protocol error (errno = 71) >>> >>> which is a bit confusing to me. I could be nicer to have that report that it >>> really was the callback that cause...

...8 @@ main (int argc, char *argv[]) { struct nbd_handle *nbd; int64_t exportsize; + struct data data; + char c; if (argc != 3) { fprintf (stderr, "%s unixsocket bitmap\n", argv[0]); @@ -108,17 +127,37 @@ main (int argc, char *argv[]) exit (EXIT_FAILURE); } - if (nbd_block_status (nbd, exportsize, 0, NULL, cb, 0) == -1) { + data = (struct data) { .count = 2, }; + if (nbd_block_status (nbd, exportsize, 0, &data, cb, 0) == -1) { fprintf (stderr, "%s\n", nbd_get_error ()); exit (EXIT_FAILURE); } - assert (calls == 0x11); - if (nbd_block_status (n...

Rather than moving the connection to DEAD, we can just ignore further contexts to the existing command handle, and fail the overall command with the same errno as the failed callback. Eric Blake (2): states: Track cmd->error as errno, not wire value api: Recover from block status callback failure generator/generator | 5 ++- generator/states-reply-simple.c | 2 +-

...h (r) { case -1: if (error) diff --git a/interop/dirty-bitmap.c b/interop/dirty-bitmap.c index aca0564..5a22adc 100644 --- a/interop/dirty-bitmap.c +++ b/interop/dirty-bitmap.c @@ -140,14 +140,17 @@ main (int argc, char *argv[]) } data = (struct data) { .count = 2, }; - if (nbd_block_status (nbd, exportsize, 0, cb, &data, 0) == -1) { + if (nbd_block_status (nbd, exportsize, 0, + (nbd_extent_callback) { .callback = cb, .user_data = &data }, + 0) == -1) { fprintf (stderr, "%s\n", nbd_get_error ()); exit (EXIT_FAI...

The callback (e.g. for `nbd_block_status`) now has a support for returning errors thanks to the last parameter (`int *error`), so it was switched to returning void. But that was not switched everywhere and some code expects it to return `int`. Yet another inconsistency is in the debug callback, which is supposed to return `void`, I gues...

Rich recently patched things to generate one man page per function rather than libnbd-api.3 (nice), but in doing so got stumped by a problem with a fresh git clone (automake fails for any 'include' directive that does not already exist). I've figured out how to hack around it, but the hack requires GNU make. We already use GNU make constructs elsewhere (such as $(wildcard)), but

...was kind of confusing). There's a bit of magic in nbdkit about $nbd. It also predates our standardization effort for NBD URLs which is going on upstream. That needs to be fixed, but in the meantime just use $unixsocket instead (see nbdkit-captive(1) man page for the full details). > When nbd_block_status() callback returns -1, the nbd_block_status() function > reports: > > command failed: Protocol error (errno = 71) > > which is a bit confusing to me. I could be nicer to have that report that it > really was the callback that caused this. Not sure about this one - Eric? >...

...rn the current number of requested meta contexts"; + longdesc = "\ +During connection libnbd can negotiate zero or more metadata +contexts with the server. Metadata contexts are features (such +as C<\"base:allocation\">) which describe information returned +by the L<nbd_block_status(3)> command (for C<\"base:allocation\"> +this is whether blocks of data are allocated, zero or sparse). + +This command returns how many meta contexts have been added to +the list to request from the server via L<nbd_add_meta_context(3)>. +The server is not obligated to hon...

RFC because this is an API break, but we haven't declared stable API yet. If we like it, I'm working on using libnbd to implement the nbdkit-nbd plugin; knowing whether it is API version 0.1 or 0.2 will be useful. I also dabbled with allowing optional parameters in python, although my OCaml is weak enough that there may be cleaner ways to approach that. Eric Blake (4): api: Add flags

On Thu, Jul 11, 2019 at 09:35:02AM -0500, Eric Blake wrote: >On 7/11/19 9:23 AM, Martin Kletzander wrote: >> The callback (e.g. for `nbd_block_status`) now has a support for returning >> errors thanks to the last parameter (`int *error`), so it was switched to >> returning void. > >No, the callback still returns int. Where are you seeing it return >void, because that's wrong. The documentation states that *error is &gt...

...meta-context). An application compiled and run with libnbd 1.16 that requests nbd_add_meta_context(h, "x-context:big") will fail to negotiate that context, but can still succeed at negotiating "base:allocation". What's more, that application was compiled at a time when the nbd_block_status_64() API did not exist, so it will necessarily be using the older 32-bit nbd_block_status() API. With the approach done in this patch (that is, the same client now linking against libnbd 1.18 defaults to unconditionally requesting extended headers), the negotiation for "x-context:big" wi...

.../code.py", line 90, in runcode exec(code, self.locals) File "<console>", line 1, in <module> File "/home/eblake/libnbd/python/nbd.py", line 577, in block_status return libnbdmod.block_status (self._o, count, offset, data, extent, flags) RuntimeError: nbd_block_status: invalid server reply length Signed-off-by: Eric Blake <eblake@redhat.com> --- server/extents.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/server/extents.c b/server/extents.c index c4224916..0ebd77b1 100644 --- a/server/extents.c +++ b/server/extents.c @@...

...0644 --- a/sh/nbdsh.pod +++ b/sh/nbdsh.pod @@ -56,6 +56,15 @@ __EXAMPLES_HEXDUMP__ Display brief command line help and exit. +=item B<-b> + +=item B<--base-allocation> + +Request the use of the "base:allocation" meta context, which is the +most common context used with L<nbd_block_status(3)>. This is +equivalent to calling S<C<h.set_meta_context +(nbd.CONTEXT_BASE_ALLOCATION)>> in the shell prior to connecting. + =item B<-c> 'COMMAND ...' =item B<--command> 'COMMAND ...' diff --git a/python/nbdsh.py b/python/nbdsh.py index 319b0f0..00b...

...t - all things we can check client-side without traffic to the server), then the callback function was NOT registered, and the user must clean any resources then and there to avoid a leak. Only when nbd_aio_FOO() succeeds will the responsibility for cleanup be handled by the callback. But for nbd_block_status and nbd_pread_structured, we have a second callback. And _these_ callbacks have a problem: we can return -1 for two different reasons, either because the command was never attempted (nbd_aio_FOO failed) and so the callback will never be cleaned, or because the command got sent to the server an...

...ow level asynchronous equivalents (eg. C<nbd_aio_pread> for +starting a command, and C<nbd_aio_pread_notify> for also registering +a callback to be invoked right before the command is complete). + +=head1 CALLBACKS + +Some of the high-level commands (C<nbd_pread_structured>, +C<nbd_block_status>) involve the use of a callback function invoked by +the state machine at appropriate points in the server's reply before +the overall command is complete. Also, all of the low-level commands +have a notify variant that registers a callback function used right +before the command is marked c...