search for: fuas

Two hopefully useful additions to the fua filter. The second one is kind of like cache=unsafe in qemu, in that it exchanges correctness for speed. Useful for data which is easily recreated in the event of a crash or for people who like living on the edge and have good backups. Rich.

This drops all FUA and flush requests. --- filters/fua/nbdkit-fua-filter.pod | 27 +++++++++++++++++---- filters/fua/fua.c | 39 +++++++++++++++++++++++++++---- tests/test-fua.sh | 33 ++++++++++++++++---------- 3 files changed, 79 insertions(+), 20 deletions(-) diff --git a/filters/fua/nbdkit-fua-filter.pod b/filters/fua/nbdkit-fua-filter.pod index

Commit b5ce88e889a2df4baa0b73033f7302e5b40f0570 fixed the cases where multiple filters are placed in front of a plugin, so that now .prepare and .finalize methods are called properly in the second and subsequent filters. This causes an additional log message to be emitted (correctly) from the newly called .prepare method in the log filter: 2018-08-01 15:17:45.249533 connection=1 Connect [...]

On Wed, Apr 11, 2018 at 12:03:41AM -0500, Eric Blake wrote: > +=item C<can_fua> > + > +(Optional) > + > + def can_fua(h): > + # return a boolean > + > +Unlike the C counterpart, the Python callback does not need a > +tri-state return value, because Python introspection is sufficient to > +learn whether callbacks support FUA. Thus, this function only returns

On 5/22/20 4:32 PM, Richard W.M. Jones wrote: > This drops all FUA and flush requests. > --- > filters/fua/nbdkit-fua-filter.pod | 27 +++++++++++++++++---- > filters/fua/fua.c | 39 +++++++++++++++++++++++++++---- > tests/test-fua.sh | 33 ++++++++++++++++---------- > 3 files changed, 79 insertions(+), 20 deletions(-) Overall, the series

On 08/01/2018 10:21 AM, Richard W.M. Jones wrote: > Commit b5ce88e889a2df4baa0b73033f7302e5b40f0570 fixed the cases where > multiple filters are placed in front of a plugin, so that now .prepare > and .finalize methods are called properly in the second and subsequent > filters. > > This causes an additional log message to be emitted (correctly) from > the newly called

Expose support for the FUA flag to pwrite, zero, and trim, as well as a can_fua callback, for use in python plugins. There are some slight semantic differences: the C plugin had to switch to a new API with a single uint32_t flags argument (so we don't have to keep adding new ABI when new flags are added), but in so doing, there is no way to probe whether a C plugin supports FUA flags, so the

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

[still a work in progress, as I finish rebasing to capture the ideas raised on the list, but posting now for initial feedback] 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

We document that a plugin callback should return 0 on success, but other places in the code treat all values other than -1 as success (perhaps we should treat all negative values as errors, instead of exactly -1, but that may break binary back-compatibility). However, when reworking where FUA fallback occurs, we introduced a subtle change: if a plugin returns a positive value on success, and the

First out of our four language bindings to add FUA support (for reference, I added 'zero' support for python, perl, and ruby back in 1.1.13, then Rich had to add it for ocaml in 1.1.20). I tested this heavily under python 2, but for now only compile tested under python 3; I plan to do further testing there and make any tweaks if necessary. I wrote patch 5 early on, but then realized I

Hi, We've been using a modified nbdkit (ours is cbdkit internally) for about half a year now and since you guys appear to be working on a next version of the API I wanted to go over some of the limitations we hit with nbdkit that we think others may also hit for consideration into the batch of changes you are making to the api. About Us: Our primary use for nbdkit is to facilitate a disk

--- docs/nbdkit-captive.pod | 4 ++-- docs/nbdkit-plugin.pod | 2 +- docs/nbdkit-service.pod | 2 +- docs/nbdkit-tls.pod | 2 +- filters/cow/nbdkit-cow-filter.pod | 4 ++-- filters/delay/nbdkit-delay-filter.pod | 2 +- filters/error/nbdkit-error-filter.pod | 6 +++---

On 01/26/2017 04:18 AM, Richard W.M. Jones wrote: > On Wed, Jan 25, 2017 at 08:55:18PM -0600, Eric Blake wrote: >> On 01/20/2017 02:16 PM, Eric Blake wrote: >>> Reject rather than silently ignoring unknown client request flags. >>> >> >>> >>> + /* Validate flags */ >>> + if (flags & ~NBD_CMD_FLAG_FUA) { >>> +

--- docs/nbdkit-captive.pod | 4 ++-- docs/nbdkit-plugin.pod | 2 +- docs/nbdkit-service.pod | 2 +- docs/nbdkit-tls.pod | 2 +- filters/cow/nbdkit-cow-filter.pod | 4 ++-- filters/delay/nbdkit-delay-filter.pod | 2 +- filters/error/nbdkit-error-filter.pod | 6 +++---

As mentioned in my reviews, I wonder if we should make our python callbacks look a bit more Pythonic by having kwargs added for each new flag that we want to expose. The idea was first floated here: https://www.redhat.com/archives/libguestfs/2018-April/msg00108.html Note that with my proposal, there is no need for a python script to expose a global API_VERSION variable; new flags are added

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

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 Fri, Jan 19, 2018 at 07:40:29AM -0600, Eric Blake wrote: > =head1 SYNOPSIS > > + #define NBDKIT_API_VERSION 2 > + > #include <nbdkit-plugin.h> > > #define THREAD_MODEL NBDKIT_THREAD_MODEL_SERIALIZE_ALL_REQUESTS > @@ -51,9 +53,21 @@ L<nbdkit-perl-plugin(3)>, > L<nbdkit-python-plugin(3)>, > L<nbdkit-ruby-plugin(3)>. > >

After more than a month since v2 [1], I've finally got my FUA support series polished. This is all of my outstanding patches, even though some of them were originally posted in separate threads from the original FUA post [2], [3] [1] https://www.redhat.com/archives/libguestfs/2018-January/msg00113.html [2] https://www.redhat.com/archives/libguestfs/2018-January/msg00219.html [3]