search for: get_errors

This patch fixes a crash in disk.c32 owing to the change in get_error()'s signature. Instead of calling get_error() I just dump the error code. don diff --git a/com32/modules/disk.c b/com32/modules/disk.c index e94a36b..2966173 100644 --- a/com32/modules/disk.c +++ b/com32/modules/disk.c @@ -37,11 +37,8 @@ int main(int argc __attribute__ (( unused )), continue;

The concern is a client is blocked while processing a request. The nbdkit server design requires a thread per request being processed regardless of the number of connections or clients. We want to run 1000's of requests in parallel without needing a thread at nbdkit layer per request in flight. Our plugin layer is built around boost asio and a few threads in a worker pool running an io

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

I ran into these while trying to prepare patches to add NBD_CMD_FLAG_FAST_ZERO, which will expose a new NBD_ENOTSUP wire value. Eric Blake (2): plugins: Don't lose original error when emulating FUA plugins: Permit ENOTSUP as synonym for EOPNOTSUPP docs/nbdkit-filter.pod | 11 ++++++----- docs/nbdkit-plugin.pod | 12 +++++++----- plugins/file/file.c | 16 +++++++++++-----

It is very unlikely that the value of errno after completing the glue code in between the completion of the user's callback and the point in time where we construct the client's reply is going to be untouched, which means that we are likely to send the wrong error code across the wire. Add a new callback which determines whether we can trust errno; defaulting to true for C plugins, where

I want to make my nbd forwarding plugin fully parallel - but to do that, I first need to make nbdkit itself fully parallel ;) With this series, I was finally able to demonstrate out-of-order responses when using qemu-io (which is great at sending back-to-back requests prior to waiting for responses) coupled with the nbd file plugin (which has a great feature of rdelay and wdelay, to make it

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

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

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

Introduce the concept of a backend. Currently the only type of backend is a plugin, and there can only be one of them. Instead of calling functions like ‘plugin_pwrite’ you call the backend method ‘backend->pwrite (backend, ...)’. The change is largely mechanical. I was able to remove ‘assert (dl)’ statements throughout since we can now prove they will never be called. Note this does not

Introduce the concept of a backend. Currently the only type of backend is a plugin, and there can only be one of them. Instead of calling functions like ‘plugin_pwrite’ you call the backend method ‘backend->pwrite (backend, ...)’. The change is largely mechanical. I was able to remove ‘assert (dl)’ statements throughout since we can now prove they will never be called. Note this does not

Introduce the concept of a backend. Currently the only type of backend is a plugin, and there can only be one of them. Instead of calling functions like ‘plugin_pwrite’ you call the backend method ‘backend->pwrite (backend, ...)’. The change is largely mechanical. I was able to remove ‘assert (dl)’ statements throughout since we can now prove they will never be called. Note this does not

This cleans up the existing code base with regards to implicit use of errno from language bindings, then rebases the previous work in python on top of that. I'm still playing with the perl bindings, but got further after reading 'perldoc perlembed'. Eric Blake (4): plugins: Don't use bogus errno from non-C plugins plugins: Add new nbdkit_set_error() utility function python:

On 8/17/20 1:46 PM, Daniel P. Berrangé wrote: > On Mon, Aug 17, 2020 at 07:36:00PM +0100, Richard W.M. Jones wrote: >> The Windows port of nbdkit >> (https://github.com/rwmjones/nbdkit/tree/2020-windows-mingw) now works >> to some extent. However errno handling doesn't work. The way that >> Winsock handles errors is incompatible with the way we expect to work

Tested via: term1$ qemu-nbd -k $PWD/sock -t -f raw -x foo junk --trace=nbd_\* term2$ ./nbdkit -f -v -e bar nbd socket=$PWD/sock export=foo term3$ qemu-io -t none -f raw nbd://localhost:10809/bar --trace=nbd_\* and checking the traces to see that 'w 0 1' vs. 'w -f 0 1' was able to influence whether the FUA flag showed up at the server in term1. Still to go: figure out how to

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

The Windows port of nbdkit (https://github.com/rwmjones/nbdkit/tree/2020-windows-mingw) now works to some extent. However errno handling doesn't work. The way that Winsock handles errors is incompatible with the way we expect to work errno in several ways. The long story is here: https://docs.microsoft.com/en-us/windows/win32/winsock/error-codes-errno-h-errno-and-wsagetlasterror-2

This morning I discovered this in the logwatch report for our external MX backup host. STARTTLS: write error=syscall error (-1), errno=32, get_error=error:00000000:lib(0):func(0):reason(0), retry=99, ssl_err=5: 206 Time(s) I also see many entries similar to this: 8: fl=0x802, mode=140777: SOCK inet04.mississauga.harte-lyne.ca/34091->(Transport endpoint is not connected): 1 Time(s)

Since v1: add the blocksize filter, add testsuite coverage of the log filter, several fixes to the log filter based on what adding tests revealed I'm still working on FUA flag support patches on top of this; the patches should all be committed in the same release, as we want to minimize the number of releases that cause a filter ABI/API bump Eric Blake (3): backend: Rework internal/filter

v1 -> v2: - Fixed everything mentioned in the review. Rich.