search for: _zero_v1

...) - return p->plugin.can_fast_zero (handle); + return normalize_bool (p->plugin.can_fast_zero (handle)); /* Advertise support for fast zeroes if no .zero or .can_zero is * false: in those cases, we fail fast instead of using .pwrite. * This also works when v1 plugin has only ._zero_v1. @@ -399,7 +407,7 @@ plugin_can_extents (struct backend *b, void *handle) struct backend_plugin *p = container_of (b, struct backend_plugin, backend); if (p->plugin.can_extents) - return p->plugin.can_extents (handle); + return normalize_bool (p->plugin.can_extents (handle));...

...plugin.can_fast_zero (handle); > + return normalize_bool (p->plugin.can_fast_zero (handle)); > /* Advertise support for fast zeroes if no .zero or .can_zero is > * false: in those cases, we fail fast instead of using .pwrite. > * This also works when v1 plugin has only ._zero_v1. > @@ -399,7 +407,7 @@ plugin_can_extents (struct backend *b, void *handle) > struct backend_plugin *p = container_of (b, struct backend_plugin, backend); > > if (p->plugin.can_extents) > - return p->plugin.can_extents (handle); > + return normalize_bool (p->...

On 3/18/20 8:21 PM, Eric Blake wrote: > In commit c306fa93ab and neighbors (v1.15.1), a concerted effort went > into caching the results of .can_FOO callbacks, with commit messages > demonstrating that a plugin with a slow callback should not have that > delay magnified multiple times. But nothing was added to the > testsuite at the time, and with the sh and eval plugins, we still

Either patch 1 or patch 2 in isolation is sufficient to fix the problem that Rich forwarded on from an archlinux tester (name so I can credit them?). But both patches should be applied, as well as backported to appropriate stable branches, to maximize cross-version interoperability of nbdkit vs. plugins. Patch 3 will let us detect future similar bugs much faster. I want patch 4 to ensure that