search for: nbd_aio_disconnect

...if (nbd_aio_pwrite (nbd, buf, 2 * 1024 * 1024, 0, 0) == -1) { fprintf (stderr, "%s: %s\n", argv[0], nbd_get_error ()); @@ -184,10 +184,13 @@ main (int argc, char *argv[]) fprintf (stderr, "%s: %s\n", argv[0], nbd_get_error ()); exit (EXIT_FAILURE); } - if (nbd_aio_disconnect (nbd, 0) == -1) { /* XXX */ - fprintf (stderr, "%s: %s\n", argv[0], nbd_get_error ()); + if (nbd_aio_disconnect (nbd, 0) != -1) { + fprintf (stderr, "%s: test failed: " + "no diagnosis that nbd_aio_disconnect prevents new commands\n", + a...

As mentioned in commits 176fc4ea and 609c25f0, our original plan in adding a flags argument to nbd_shutdown was to let us specify different behaviors at the libnbd level, rather than NBD protocol flags (for that, the user has nbd_aio_disconnect). But when we later parameterized OFlags to accept various bitmasks (commit f891340b), we failed to mark nbd_shutdown as using a different bitmask than NBD_CMD_FLAG. I've finally found a use for such a flag. By itself, nbd_aio_disconnect merely queues itself at the back of all pending comman...

...EADY state into two - one for when there are no commands in flight (and get_direction returns 0 to state that polling is pointless, although a multi-threaded reader can still poll for POLLIN), and the other when there ARE commands in flight. Such a separation would also make it easier to know when nbd_aio_disconnect is not going to strand an in-flight command's response. But I'm not sure it is worth the effort. --- I'm pushing this one now, but sending the email because of the question it raises on whether we want the user to be able to distinguish a difference between any vs. no in-flight command...

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

...t 09:31:11AM -0500, Eric Blake wrote: >> As mentioned in commits 176fc4ea and 609c25f0, our original plan in >> adding a flags argument to nbd_shutdown was to let us specify >> different behaviors at the libnbd level, rather than NBD protocol >> flags (for that, the user has nbd_aio_disconnect). But when we later >> parameterized OFlags to accept various bitmasks (commit f891340b), we >> failed to mark nbd_shutdown as using a different bitmask than >> NBD_CMD_FLAG. >> >> I've finally found a use for such a flag. By itself, >> nbd_aio_disconnect m...

..., Sep 11, 2020 at 09:31:11AM -0500, Eric Blake wrote: > As mentioned in commits 176fc4ea and 609c25f0, our original plan in > adding a flags argument to nbd_shutdown was to let us specify > different behaviors at the libnbd level, rather than NBD protocol > flags (for that, the user has nbd_aio_disconnect). But when we later > parameterized OFlags to accept various bitmasks (commit f891340b), we > failed to mark nbd_shutdown as using a different bitmask than > NBD_CMD_FLAG. > > I've finally found a use for such a flag. By itself, > nbd_aio_disconnect merely queues itself at t...

...bd_get_error ()); + exit (EXIT_FAILURE); + } + if ((nbd_aio_get_direction (nbd) & LIBNBD_AIO_DIRECTION_WRITE) == 0) { + fprintf (stderr, "%s: test failed: " + "expect to be blocked on write\n", + argv[0]); + exit (EXIT_FAILURE); + } + if (nbd_aio_disconnect (nbd, 0) == -1) { + fprintf (stderr, "%s: %s\n", argv[0], nbd_get_error ()); + exit (EXIT_FAILURE); + } + if (nbd_aio_disconnect (nbd, 0) == -1) { /* XXX */ + fprintf (stderr, "%s: %s\n", argv[0], nbd_get_error ()); + exit (EXIT_FAILURE); + } + + /* Flush the que...

...- one for when there > are no commands in flight (and get_direction returns 0 to state that > polling is pointless, although a multi-threaded reader can still poll > for POLLIN), and the other when there ARE commands in flight. Such a > separation would also make it easier to know when nbd_aio_disconnect > is not going to strand an in-flight command's response. But I'm not > sure it is worth the effort. > --- > > I'm pushing this one now, but sending the email because of the > question it raises on whether we want the user to be able to > distinguish a difference b...

...1 deletion(-) diff --git a/plugins/nbd/nbd.c b/plugins/nbd/nbd.c index ba1e7188..0ea2a4a2 100644 --- a/plugins/nbd/nbd.c +++ b/plugins/nbd/nbd.c @@ -532,7 +532,7 @@ nbdplug_open (int readonly) static void nbdplug_close_handle (struct handle *h) { - if (nbd_shutdown (h->nbd, 0) == -1) + if (nbd_aio_disconnect (h->nbd, 0) == -1) nbdkit_debug ("failed to clean up handle: %s", nbd_get_error ()); if ((errno = pthread_join (h->reader, NULL))) nbdkit_debug ("failed to join reader thread: %m"); -- 2.26.0.rc2

...ite \ - nbd_shutdown \ - nbd_flush \ - nbd_trim \ - nbd_cache \ - nbd_zero \ - nbd_block_status \ - nbd_poll \ - nbd_aio_connect \ - nbd_aio_connect_uri \ - nbd_aio_connect_unix \ - nbd_aio_connect_tcp \ - nbd_aio_connect_command \ - nbd_aio_pread \ - nbd_aio_pread_structured \ - nbd_aio_pwrite \ - nbd_aio_disconnect \ - nbd_aio_flush \ - nbd_aio_trim \ - nbd_aio_cache \ - nbd_aio_zero \ - nbd_aio_block_status \ - nbd_aio_get_fd \ - nbd_aio_get_direction \ - nbd_aio_notify_read \ - nbd_aio_notify_write \ - nbd_aio_is_created \ - nbd_aio_is_connecting \ - nbd_aio_is_ready \ - nbd_aio_is_processing \ - nbd_aio_is...

...ite \ + nbd_shutdown \ + nbd_flush \ + nbd_trim \ + nbd_cache \ + nbd_zero \ + nbd_block_status \ + nbd_poll \ + nbd_aio_connect \ + nbd_aio_connect_uri \ + nbd_aio_connect_unix \ + nbd_aio_connect_tcp \ + nbd_aio_connect_command \ + nbd_aio_pread \ + nbd_aio_pread_structured \ + nbd_aio_pwrite \ + nbd_aio_disconnect \ + nbd_aio_flush \ + nbd_aio_trim \ + nbd_aio_cache \ + nbd_aio_zero \ + nbd_aio_block_status \ + nbd_aio_get_fd \ + nbd_aio_get_direction \ + nbd_aio_notify_read \ + nbd_aio_notify_write \ + nbd_aio_is_created \ + nbd_aio_is_connecting \ + nbd_aio_is_ready \ + nbd_aio_is_processing \ + nbd_aio_is...

On Fri, Mar 27, 2020 at 05:33:28PM -0500, Eric Blake wrote: > We have been seeing sporadic hangs on test-nbd-tls-psk.sh, where even > though the client to the 'nbdkit nbd' process has cleanly exited, > things are stalled in .close where nbd is trying to pthread_join() the > reader thread, while the reader thread is itself blocked on a poll() > that will never make additional

...+ exit (EXIT_FAILURE); + } if ((nbd_aio_get_direction (nbd) & LIBNBD_AIO_DIRECTION_WRITE) == 0) { fprintf (stderr, "%s: test failed: " "expect to be blocked on write\n", @@ -192,6 +268,17 @@ main (int argc, char *argv[]) } check (EINVAL, "nbd_aio_disconnect: "); + /* Unblock the nbdkit sh plugin */ + if (close (witness_fd) == -1) { + perror ("close"); + exit (EXIT_FAILURE); + } + witness_fd = -1; + if (unlink (witness) == -1) { + perror ("unlink"); + exit (EXIT_FAILURE); + } + /* Flush the queue (whether...

...quot;check how many aio commands are still in flight"; + longdesc = "\ +Return the number of in-flight aio commands that are still awaiting a +response from the server before they can be retired. If this returns +a non-zero value when requesting a disconnect from the server (see +C<nbd_aio_disconnect> and C<nbd_shutdown>), libnbd does not try to +wait for those commands to complete gracefully; if the server strands +commands while shutting down, C<nbd_aio_command_completed> will not +be able to report status on those commands."; + }; + "connection_state", {...

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

[Dropping devel, adding libguestfs] This can be reproduced on x86-64 so I can reproduce it locally. It only appears to happen when the tests are run under rpmbuild, not when I run them as ‘make check’, but I'm unclear why this is. As Eric described earlier, the test runs two copies of nbdkit and a client, connected like this: qemu-img info ===> nbdkit nbd ===> nbdkit example1

..."); UInt64 "offset"; UInt32 "flags" ]; + args = [ BytesIn ("buf", "count"); UInt64 "offset"; Flags "flags" ]; ret = RErr; shortdesc = "write to the NBD server"; longdesc = "\ @@ -1276,7 +1277,7 @@ C<nbd_aio_disconnect>."; "flush", { default_call with - args = [ UInt32 "flags" ]; ret = RErr; + args = [ Flags "flags" ]; ret = RErr; shortdesc = "flushing pending write requests"; longdesc = "\ Issue the flush command to the NBD server....

nbdkit 1.2 as a server waits for read() to see EOF, even after the client has sent NBD_CMD_DISC. That was fixed in mbdkit 1.4; and most modern NBD servers are smarter than this (they close() the write end of their traffic soon after NBD_CMD_DISC). But it's easy enough to revert nbdkit commit c70616f8 to get back to a server with the same behavior as the older nbdkit, at which point both

This applies on top of patches 1 & 2 here (instead of patch 3): https://www.redhat.com/archives/libguestfs/2019-May/msg00206.html https://www.redhat.com/archives/libguestfs/2019-May/msg00207.html Rich.

I still need to wire in the use of *_notify functions into nbdkit to prove whether it makes the code any faster or easier to maintain, but at least the added example shows one good use case for the new API. Eric Blake (6): api: Add nbd_aio_in_flight generator: Allow DEAD state actions to run generator: Allow Int64 in callbacks states: Prepare for aio notify callback api: Add new