similar to: question on nbdkit sh plugin

On Thu, Aug 31, 2023 at 11:12:59AM +0200, Laszlo Ersek wrote: > On 8/31/23 10:02, Richard W.M. Jones wrote: > > > > On Wed, Aug 30, 2023 at 05:21:19PM -0500, Eric Blake wrote: > >> I hit another transient failure in libnbd CI when a poorly-written > >> eval script did not consume all of stdin during .pwrite. As behaving > >> as a data sink can be a

I hit another transient failure in libnbd CI when a poorly-written eval script did not consume all of stdin during .pwrite. As behaving as a data sink can be a somewhat reasonable feature of a quickly-written sh or eval plugin, we should not be so insistent as treating an EPIPE failure as an immediate return of EIO to the client. Signed-off-by: Eric Blake <eblake at redhat.com> --- I

On 8/31/23 10:02, Richard W.M. Jones wrote: > > On Wed, Aug 30, 2023 at 05:21:19PM -0500, Eric Blake wrote: >> I hit another transient failure in libnbd CI when a poorly-written >> eval script did not consume all of stdin during .pwrite. As behaving >> as a data sink can be a somewhat reasonable feature of a >> quickly-written sh or eval plugin, we should not be so

On 8/31/23 00:21, Eric Blake wrote: > I hit another transient failure in libnbd CI when a poorly-written > eval script did not consume all of stdin during .pwrite. As behaving > as a data sink can be a somewhat reasonable feature of a > quickly-written sh or eval plugin, we should not be so insistent as > treating an EPIPE failure as an immediate return of EIO to the client. >

On Thu, Aug 31, 2023 at 10:40:53AM +0200, Laszlo Ersek wrote: > On 8/31/23 00:21, Eric Blake wrote: > > I hit another transient failure in libnbd CI when a poorly-written > > eval script did not consume all of stdin during .pwrite. As behaving > > as a data sink can be a somewhat reasonable feature of a > > quickly-written sh or eval plugin, we should not be so

On Wed, Aug 30, 2023 at 05:21:19PM -0500, Eric Blake wrote: > I hit another transient failure in libnbd CI when a poorly-written > eval script did not consume all of stdin during .pwrite. As behaving > as a data sink can be a somewhat reasonable feature of a > quickly-written sh or eval plugin, we should not be so insistent as > treating an EPIPE failure as an immediate return of

On 8/31/23 10:55, Richard W.M. Jones wrote: > On Thu, Aug 31, 2023 at 10:40:53AM +0200, Laszlo Ersek wrote: >> On 8/31/23 00:21, Eric Blake wrote: >>> I hit another transient failure in libnbd CI when a poorly-written >>> eval script did not consume all of stdin during .pwrite. As behaving >>> as a data sink can be a somewhat reasonable feature of a

On Thu, Aug 31, 2023 at 11:18:27AM +0200, Laszlo Ersek wrote: > On 8/31/23 10:55, Richard W.M. Jones wrote: > > On Thu, Aug 31, 2023 at 10:40:53AM +0200, Laszlo Ersek wrote: > >> On 8/31/23 00:21, Eric Blake wrote: > >>> I hit another transient failure in libnbd CI when a poorly-written > >>> eval script did not consume all of stdin during .pwrite. As

On Thu, Aug 31, 2023 at 12:05:17PM +0200, Laszlo Ersek wrote: > On 8/31/23 11:47, Richard W.M. Jones wrote: > > On Thu, Aug 31, 2023 at 11:12:59AM +0200, Laszlo Ersek wrote: > >> On 8/31/23 10:02, Richard W.M. Jones wrote: > >>> > >>> On Wed, Aug 30, 2023 at 05:21:19PM -0500, Eric Blake wrote: > >>>> I hit another transient failure in libnbd

See comment for explanation and https://listman.redhat.com/archives/libguestfs/2023-August/032468.html --- tests/Makefile.am | 2 + plugins/sh/call.c | 33 +++++++----- tests/test-sh-pwrite-ignore-stdin.sh | 77 ++++++++++++++++++++++++++++ 3 files changed, 100 insertions(+), 12 deletions(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index

Technically, as long as our thread model is SERIALIZE_ALL_REQUESTS, we don't have to be very careful about atomic CLOEXEC on any of the pipes we create for communication with the child. However, the next patch wants to promote sh plugin to parallel when possible, which requires the use of pipe2 to avoid fd leaks. Also, add an assert to ensure that we avoid dup2(n, n) (which would fail to

As long as we have SERIALIZE_ALL_REQUESTS, we don't have to worry about one thread processing a fork() while another thread might be opening an fd. But add comments to the code to remind us to fix things if we ever decide to add more parallelism. Signed-off-by: Eric Blake <eblake@redhat.com> --- plugins/sh/call.c | 4 ++++ plugins/sh/sh.c | 3 +++ 2 files changed, 7 insertions(+)

From: "Richard W.M. Jones" <rjones@redhat.com> This patch may be worth squashing? --- docs/nbdkit-filter.pod | 65 +++++++++++++++++++++++++++++++++++++++++++------ include/nbdkit-filter.h | 29 ++++++++++++---------- src/filters.c | 55 ++++++++++++++++++++--------------------- 3 files changed, 101 insertions(+), 48 deletions(-) diff --git a/docs/nbdkit-filter.pod

On Fri, Jan 19, 2018 at 10:45:51AM -0600, Eric Blake wrote: > I'm wondering if we're missing documentation here (and/or in the plugins > document) that if .can_write returns true, the plugin must supply a > .pwrite; likewise for .can_trim implying a .trim, and .can_flush > implying a .flush. It's a strange one. For example if a plugin returns .can_pwrite == 1 but

On 7/9/20 12:08 PM, Richard W.M. Jones wrote: > On Thu, Jul 09, 2020 at 11:37:53AM -0500, Eric Blake wrote: >> Since .prepare is called before client negotiation has completed, >> filters have an additional burden to ensure prerequisite functions are >> called in order to avoid triggering assertions in backend.c. >> >> See also:

I'm not sure that this fix is really correct. An alternate way I can think to fix this would be for the core server to maintain a readonly flag for each layer (instead of just per- server). You could also argue that our readonly test in server/connections.c:compute_eflags is wrong and/or that the implementations of server/plugins.c:plugin_can_write and server/filters.c:filter_can_write have

Since .prepare is called before client negotiation has completed, filters have an additional burden to ensure prerequisite functions are called in order to avoid triggering assertions in backend.c. See also: https://bugzilla.redhat.com/show_bug.cgi?id=1855330, https://www.redhat.com/archives/libguestfs/2020-July/msg00041.html Signed-off-by: Eric Blake <eblake@redhat.com> ---

Some feature additions to the shell script plugin allow us to test the export flags field reasonably easily. Rich.

v1 was here: https://www.redhat.com/archives/libguestfs/2018-December/thread.html#00123 v2: - Document "-" instead of "script=-" and use it in the test; and verify this also works on FreeBSD; and verify that it doesn't depend on the particular behaviour of our wrapper script and should work with installed nbdkit too. - Fix handling of zero flags parameter. -

And fill out most of the missing bits of the API. Rich.