search for: log_verify_seen_in_order

...s/test-layers.c @@ -282,19 +282,20 @@ main (int argc, char *argv[]) "test_layers_plugin_config_complete", NULL); - /* open methods called in order. */ + /* open methods called in outer-to-inner order, but thanks to next + * pointer, complete in inner-to-outer order. */ log_verify_seen_in_order ("testlayersfilter3: open readonly=0", - "filter3: test_layers_filter_open", "testlayersfilter2: open readonly=0", - "filter2: test_layers_filter_open", "testlayersfilter1: open readonly=0", - "filter1: test_layers_...

...--git a/tests/test-layers.c b/tests/test-layers.c index db0a2da0..fa7730e6 100644 --- a/tests/test-layers.c +++ b/tests/test-layers.c @@ -331,6 +331,18 @@ main (int argc, char *argv[]) * than open-coding a naive client. */ + /* .default_export methods called in outer-to-inner order. */ + log_verify_seen_in_order + ("testlayersfilter3: default_export", + "filter3: test_layers_filter_default_export", + "testlayersfilter2: default_export", + "filter2: test_layers_filter_default_export", + "testlayersfilter1: default_export", + "filt...

...t a/tests/test-layers.c b/tests/test-layers.c index eac7f15..c12af47 100644 --- a/tests/test-layers.c +++ b/tests/test-layers.c @@ -282,6 +282,18 @@ main (int argc, char *argv[]) "test_layers_plugin_config_complete", NULL); + /* ready_to_serve methods called in order. */ + log_verify_seen_in_order + ("testlayersfilter3: ready_to_serve", + "filter3: test_layers_filter_ready_to_serve", + "testlayersfilter2: ready_to_serve", + "filter2: test_layers_filter_ready_to_serve", + "testlayersfilter1: ready_to_serve", + "filt...

...rs.c > index db0a2da0..fa7730e6 100644 > --- a/tests/test-layers.c > +++ b/tests/test-layers.c > @@ -331,6 +331,18 @@ main (int argc, char *argv[]) > * than open-coding a naive client. > */ > > + /* .default_export methods called in outer-to-inner order. */ > + log_verify_seen_in_order > + ("testlayersfilter3: default_export", > + "filter3: test_layers_filter_default_export", > + "testlayersfilter2: default_export", > + "filter2: test_layers_filter_default_export", > + "testlayersfilter1: default_expor...

I'm still working on another set of patches to have reopen call .finalize/.prepare (so that another filter can safely appear between retry and the plugin), but for tonight, these are the patches I think are ready to go. Eric Blake (4): retry: Handle can_fua and can_fast_zero changes tests: Test retry with different fua/fast-zero flags server: Close backends if a filter's .open fails

...- /* list_exports methods called in outer-to-inner order, complete - * in inner-to-outer order. But since we didn't send NBD_OPT_LIST, - * the outer filter does not expose a list; rather, the rest of the - * chain is used to resolve the canonical name of the default export. - */ - log_verify_seen_in_order - ("filter3: test_layers_filter_list_exports", - "testlayersfilter2: list_exports", - "filter2: test_layers_filter_list_exports", - "testlayersfilter1: list_exports", - "filter1: test_layers_filter_list_exports", - "testl...

...s/test-layers.c b/tests/test-layers.c index 261b9c6..c8d15d2 100644 --- a/tests/test-layers.c +++ b/tests/test-layers.c @@ -349,6 +349,12 @@ main (int argc, char *argv[]) "filter1: test_layers_filter_is_rotational", "test_layers_plugin_is_rotational", NULL); + log_verify_seen_in_order + ("filter3: test_layers_filter_can_multi_conn", + "filter2: test_layers_filter_can_multi_conn", + "filter1: test_layers_filter_can_multi_conn", + "test_layers_plugin_can_multi_conn", + NULL); fprintf (stderr, "%s: protocol connec...

If you're following nbdkit development upstream you'll have seen that we are still making changes to the .list_exports and related APIs. The current .list_exports API upstream is not how it will look finally. The latest set of proposals was here: https://www.redhat.com/archives/libguestfs/2020-August/thread.html#00330 At the same time I'd like to do an nbdkit 1.22 (stable) release.

This is my second attempt at this. The first version (also not working) was here: https://www.redhat.com/archives/libguestfs/2019-October/msg00062.html In part 1/2 I introduce a new .ready_to_serve plugin method which is called after forking and just before accepting any client connection. The idea would be that plugins could start background threads here. However this doesn't work well in

Eric: Did you want to take this one any further? It might be one that we save for > 1.18: https://www.redhat.com/archives/libguestfs/2020-February/thread.html#00206 Another thing I've been thinking about for some time is splitting .config_complete into .config_complete + .get_ready (new name TBD). At the moment .config_complete is both the place where we finish processing config, and

...-git a/tests/test-layers.c b/tests/test-layers.c index fafe68c4..33ae5a75 100644 --- a/tests/test-layers.c +++ b/tests/test-layers.c @@ -288,6 +288,18 @@ main (int argc, char *argv[]) "test_layers_plugin_config_complete", NULL); + /* get_ready methods called in order. */ + log_verify_seen_in_order + ("testlayersfilter3: get_ready", + "filter3: test_layers_filter_get_ready", + "testlayersfilter2: get_ready", + "filter2: test_layers_filter_get_ready", + "testlayersfilter1: get_ready", + "filter1: test_layers_filter_g...

It's easy to use the sh script to demonstrate that nbdkit is inefficiently calling into .get_size, .can_fua, and friends more than necessary. We've also commented on the list in the past that it would be nice to ensure that when filters call into next_ops, they are not violating constraints (as we've have to fix several bugs in the past where we did not have such checking to protect

While working on can_FOO caching, at one point I got confused by whether 'readonly' meant the global set by -r or a local passed to .open(). A quick attempt to compile with -Wshadow found several other confusing points; this series gets us to the point that we can add -Wshadow to builds with --enable-gcc-warnings. Eric Blake (10): server: Avoid -Wshadow warnings guestfs: Avoid

...to resolve the canonical name of the default export. + /* XXX We should test NBD_OPT_INFO here for coverage of + * .list_exports. However it would be easier to do by using libnbd + * than open-coding a naive client. */ + + /* .default_export methods called in outer-to-inner order. */ log_verify_seen_in_order - ("filter3: test_layers_filter_list_exports", - "testlayersfilter2: list_exports", - "filter2: test_layers_filter_list_exports", - "testlayersfilter1: list_exports", - "filter1: test_layers_filter_list_exports", - "testl...

Since v1: - patch 1: check size limits - patch 2: better handling of default export name canonicalization - patch 3: support filters as well as plugins - patch 4: new - patch 5: rewrite sh parser, fix testsuite to actually work and cover more cases (now that libnbd.git is fixed) Eric Blake (4): server: Add exports list functions server: Prepare to use export list from plugin log: Add

I'm still working my way through the filters before this series will be complete, but this is enough of a start to at least get some feedback on the idea of implementing another NBD protocol extension. Eric Blake (9): server: Internal hooks for implementing NBD_CMD_CACHE plugins: Add .cache callback file, split: Implement .cache with posix_fadvise nbd: Implement NBD_CMD_CACHE

This is a revision of my .default_export work, plus new work on .export_descriptions and a new exportname filter. I think it is now ready to check in. Things I'd still like in 1.22: - the file plugin should implement .list_exports (patch already posted, but it needs rebasing on this series) - the ext2 filter should override .list_exports when in exportname mode - the nbd plugin should be

I like this change. I think we were overloading the config_complete method before to do two different things (complete configuration; do any allocation/housekeeping necessary before we can start serving). The only questions in my mind are whether we want this before 1.18, and whether the name ("get_ready") is a good one. Rich.

First thing to say is that I need to do a *lot* more testing on this, so this is just an early peek. In particular, although it passed ‘make check && make check-valgrind’ I have *not* tested it against a multi-conn-aware client such as the Linux kernel >= 4.9. This implements NBD_FLAG_CAN_MULTI_CONN, described in the protocol doc as: "NBD_FLAG_CAN_MULTI_CONN: Indicates that

For existing commits, this is almost identical to v1, except that I updated some commit messages and reordered the commits in a somewhat more logical sequence. The main changes are the extra commits: [06/11] plugins: Return NBD_FLAG_CAN_MULTI_CONN from some readonly plugins. - Readonly plugins that can set the flag unconditionally. [09/11] partitioning: Return NBD_FLAG_CAN_MULTI_CONN. [10/11]