similar to: nbdkit filter error handling

Previously, we let a plugin set an error in either thread-local storage (nbdkit_set_error()) or errno, then connections.c would decode which error to use. But with filters in the mix, it is very difficult for a filter to know what error was set by the plugin (particularly since nbdkit_set_error() has no public counterpart for reading the thread-local storage). What's more, if a filter does

On Wed, Jan 31, 2018 at 09:26:37PM -0600, Eric Blake wrote: > Previously, we let a plugin set an error in either thread-local > storage (nbdkit_set_error()) or errno, then connections.c would > decode which error to use. But with filters in the mix, it is > very difficult for a filter to know what error was set by the > plugin (particularly since nbdkit_set_error() has no public

Originally, I thought that since the plugin always emulates .zero with a fallback to .pwrite, we didn't need to expose the backend's .can_zero to plugins. But there is another consideration, as shown at least in the nbd plugin: a plugin may implement a .zero callback that depends on support from a remote endpoint. If the remote endpoint doesn't support zeroes, then the plugin HAS to

Ever since commit 69ae137f, the docs claimed that we check .errno_is_preserved == 1, but the code has checked for != 0. Furthermore, the mention of .errno_is_preserved in the docs was rather hidden; a new section will make it easier to add future knobs that likewise affect the plugin as a whole and not an individual connection. Fixes: 69ae137f Signed-off-by: Eric Blake <eblake@redhat.com>

This pair of calls allows plugins to describe which extents in the virtual disk are allocated, holes or zeroes. --- docs/nbdkit-filter.pod | 22 +++++++++++ docs/nbdkit-plugin.pod | 86 +++++++++++++++++++++++++++++++++++++++++ include/nbdkit-common.h | 14 ++++++- include/nbdkit-filter.h | 12 +++++- include/nbdkit-plugin.h | 6 ++- server/internal.h | 7 +++- server/filters.c |

This pair of calls allows plugins to describe which extents in the virtual disk are allocated, holes or zeroes. --- docs/nbdkit-filter.pod | 45 +++++++++++++++++ docs/nbdkit-plugin.pod | 106 ++++++++++++++++++++++++++++++++++++++++ include/nbdkit-common.h | 18 ++++++- include/nbdkit-filter.h | 12 ++++- include/nbdkit-plugin.h | 6 ++- server/internal.h | 7 ++- server/extents.c

This pair of calls allows plugins to describe which extents in the virtual disk are allocated, holes or zeroes. --- docs/nbdkit-filter.pod | 64 +++++++++++++++++++++ docs/nbdkit-plugin.pod | 123 ++++++++++++++++++++++++++++++++++++++++ include/nbdkit-common.h | 20 ++++++- include/nbdkit-filter.h | 15 ++++- include/nbdkit-plugin.h | 6 +- server/internal.h | 7 ++-

The NBD protocol supports Forced Unit Access (FUA) as a more efficient way to wait for just one write to land in persistent storage, rather than all outstanding writes at the time of a flush; modeled after the kernel's block I/O flag of the same name. While we can emulate the proper semantics with a full-blown flush, there are some plugins that can properly pass the FUA flag on to the end

On 01/31/2018 09:26 PM, Eric Blake wrote: > For maximum convenience, this change lets a filter return an > error either by passing through the underlying plugin return > (a positive error) or by setting -1 and storing something in > errno. For filters, this makes sense (all filters are in-tree, so we can audit that the return values follow conventions). But for plugins, we're

POSIX allows but does not require ENOTSUP and EOPNOTSUPP to map to the same errno value. This patch has no impact on Linux, but does affect other systems: we want to be permissive in what we accept (either spelling, since the two are commonly confused), while strict in what we generate (we documented EOPNOTSUPP as the trigger to fall back to .write, so stick to that internally where it makes

This pair of calls allows plugins to describe which extents in the virtual disk are allocated, holes or zeroes. --- docs/nbdkit-filter.pod | 89 +++++++++++++++++++ docs/nbdkit-plugin.pod | 96 +++++++++++++++++++++ include/nbdkit-common.h | 10 ++- include/nbdkit-filter.h | 22 ++++- include/nbdkit-plugin.h | 6 +- server/internal.h | 4 + server/extents.c | 186

This pair of calls allows plugins to describe which extents in the virtual disk are allocated, holes or zeroes. --- docs/nbdkit-filter.pod | 92 +++++++++++++++++++++ docs/nbdkit-plugin.pod | 99 +++++++++++++++++++++++ include/nbdkit-common.h | 10 ++- include/nbdkit-filter.h | 22 +++++- include/nbdkit-plugin.h | 6 +- server/internal.h | 4 + server/extents.c | 171

This new pair of callbacks allows plugins to describe which extents in the virtual disk are allocated, holes or zeroes. --- docs/nbdkit-filter.pod | 83 ++++++++++++++++ docs/nbdkit-plugin.pod | 97 +++++++++++++++++++ include/nbdkit-common.h | 10 +- include/nbdkit-filter.h | 22 ++++- include/nbdkit-plugin.h | 6 +- server/internal.h | 4 + server/extents.c | 210

>From the protocol document: "NBD_FLAG_CAN_MULTI_CONN: Indicates that the server operates entirely without cache, or that the cache it uses is shared among all connections to the given device. In particular, if this flag is present, then the effects of NBD_CMD_FLUSH and NBD_CMD_FLAG_FUA MUST be visible across all connections when the server sends its reply to that command to

The callback doesn't make much sense: Could the value change per-connection? Unlikely. This is a property of the plugin as a whole. I changed the name to "errno_is_preserved", because it's not about the reliability of errno, but about whether errno is preserved across calls. --- docs/nbdkit-plugin.pod | 37 +++++++++------------------------

Allow a plugin field to declare whether a parallel plugin can tolerate windows where fds are not CLOEXEC, or must take precautions to avoid leaking fds if the plugin may fork. For safety reasons, the flag defaults to off, but many in-tree plugins can set it to on (most commonly because they don't fork after .config_complete; for libvirt because it is documented to clean up fds on fork so it

I'm about to add an 'exportname' filter, and in the process, I noticed a few shortcomings in our API. Having .default_export makes it easy to answer NBD_INFO_NAME in response to a client request during NBD_OPT_GO, but answering NBD_INFO_DESCRIPTION is awkward - there's no guarantee the export name was given with a description in .list_exports. Note, however, that while we map

This pair of calls allows plugins to describe which extents in the virtual disk are allocated, holes or zeroes. --- docs/nbdkit-filter.pod | 107 ++++++++ docs/nbdkit-plugin.pod | 103 +++++++ include/nbdkit-common.h | 10 +- include/nbdkit-filter.h | 25 +- include/nbdkit-plugin.h | 6 +- server/internal.h | 5 + server/extents.c | 574

The NBD protocol is adding an extension to let servers advertise initialization state to the client: whether the image contains holes, and whether it is known to read as all zeroes. Most filters just pass through the plugin's result (as it is only checked once when first connecting), but we can do useful things in log (mention the setting), extentlist (answer based on the extents we are

Here's what I'm currently playing with; I'm not ready to commit anything until I rebase my FUA work on top of this, as I only want to break filter ABI once between releases. Eric Blake (2): backend: Rework internal/filter error return semantics filters: Add log filter TODO | 2 - docs/nbdkit-filter.pod | 84 +++++++-- docs/nbdkit.pod