Displaying 20 results from an estimated 10000 matches similar to: "[PATCH nbdkit 0/2] Add new retry filter."
2019 Sep 19
7
[PATCH nbdkit v2 0/4] Add new retry filter.
v1 was here:
https://www.redhat.com/archives/libguestfs/2019-September/msg00199.html
v2:
- Adds a fairly simple yet comprehensive test using sh plugin.
- Rebase and retest.
Patch 1 is a misc patch not really related to the series.
Rich.
2019 Sep 19
7
[PATCH nbdkit v3 0/3] Add new retry filter.
v2 was here:
https://www.redhat.com/archives/libguestfs/2019-September/msg00221.html
I think this is more like "the one". It handles reopen failing
correctly, and there is a second test for that. I also ran my sshd
tests locally and it worked in all scenarios I could think up (except
of course sshd not being available at the start, but we want that to
fail).
Rich.
2019 Oct 04
1
Re: [nbdkit PATCH 2/5] retry: Check size before transactions
On Thu, Oct 03, 2019 at 09:54:37PM -0500, Eric Blake wrote:
> Although it is unusual for a plugin to shrink size on reopen, it is
> not impossible. Failure to check our bounds could result in violating
> assumptions in the plugin that all requests are in-bounds. Note that
> if the plugin gains a larger size, we merely never access the new tail
> of the file (when the NBD protocol
2019 Oct 01
9
[nbdkit PATCH v2 0/6] Improve retry filter
Includes a rework of the previously posted patch for --run
improvements (mostly with improved comments and commit message; I
decided that waiting for the captive nbdkit to exit was overkill), and
four new patches. The tests are intentionally separate, to allow
rearranging the order of the series to see the failures being fixed.
Eric Blake (6):
server: Propagate unexpected nbdkit failure with
2023 Jan 27
2
[nbdkit PATCH 1/2] retry: Add in retry support during .open
Now that a filter can open a backend as many times as it wants,
there's no longer a technical reason we can't retry .open. However,
adding retry logic here does mean we have to weaken an assert in the
server backend code, since prepare can now be reached more than once.
Test coverage will be added in a separate patch, so that it becomes
easy to swap patch order and see that the test
2019 Oct 04
6
[nbdkit PATCH 0/5] Another round of retry fixes
I still don't have .prepare/.finalize working cleanly across reopen,
but did find a nasty bug where a botched assertion means we failed to
notice reads beyond EOF in both the xz and retry filter.
Refactoring backend.c will make .finalize work easier.
Eric Blake (5):
xz: Avoid reading beyond EOF
retry: Check size before transactions
tests: Test retry when get_size values change
2019 Oct 07
6
[nbdkit PATCH 0/5] More retry fixes
I think this is my last round of patches for issues I identified with
the retry filter. With this in place, it should be safe to interject
another filter in between retry and the plugin.
Eric Blake (5):
retry: Don't call into closed plugin
tests: Refactor test-retry-reopen-fail.sh
tests: Enhance retry test to cover failed reopen
server: Move prepare/finalize/close recursion to
2023 Jan 27
2
[nbdkit PATCH 0/2] retry: add support for retrying .open
In https://bugzilla.redhat.com/show_bug.cgi?id=1841820, it was pointed
out that the retry filter not retrying .open means that an ssh
connection (such as in a vmx+ssh v2v conversion) fails when the ssh
connection itself cannot be retried. A year ago, this was an inherent
limitation of our retry implementation; but in the meantime, my work
to allow filters to open independent backends has made it
2019 Mar 26
21
[PATCH nbdkit v4 00/15] Implement Block Status.
I'm not sure exactly which version we're up to, but let's say it's
version 4.
I'm a lot happier with this version:
- all filters have been reviewed and changed where I think that's necessary
- can_extents is properly defined and implemented now
- NBD protocol is followed
- I believe it addresses all previous review points where possible
The "only" thing
2019 Oct 03
7
[nbdkit PATCH 0/4] More work with retry safety
I'm still working on another set of patches to have reopen call
.finalize/.prepare (so that another filter can safely appear between
retry and the plugin), but for tonight, these are the patches I think
are ready to go.
Eric Blake (4):
retry: Handle can_fua and can_fast_zero changes
tests: Test retry with different fua/fast-zero flags
server: Close backends if a filter's .open fails
2019 Mar 28
32
[PATCH nbdkit v5 FINAL 00/19] Implement extents.
This has already been pushed upstream. I am simply posting these here
so we have a reference in the mailing list in case we find bugs later
(as I'm sure we will - it's a complex patch series).
Great thanks to Eric Blake for tireless review on this one. It also
seems to have identified a few minor bugs in qemu along the way.
Rich.
2019 Mar 20
15
[PATCH nbdkit 0/8] Implement extents using a simpler array.
Not sure what version we're up to, but this reimplements extents using
the new simpler structure described in this thread:
https://www.redhat.com/archives/libguestfs/2019-March/msg00077.html
I also fixed most of the things that Eric pointed out in the previous
review, although I need to go back over his replies and check I've got
everything.
This needs a bit more testing. However the
2020 Aug 07
7
[nbdkit PATCH 0/3] Content differentiation during --tls=on
Patch 3 still needs tests added, but it is at least working from
my simple command line tests.
Eric Blake (3):
server: Implement nbdkit_is_tls for use during .open
server: Expose final thread_model to filter's .get_ready
tlsdummy: New filter
docs/nbdkit-filter.pod | 21 +-
docs/nbdkit-plugin.pod | 34 ++-
docs/nbdkit-tls.pod
2019 Apr 27
8
[nbdkit PATCH 0/4] Fix truncate handling of real_size
While working on adding assertions to pthread_mutex_lock calls, I
noticed that the truncate filter's use of mutex didn't really protect
us, and isn't really necessary. Cleaning that up also spotted a couple
of other potential cleanups.
Eric Blake (4):
filters: Drop useless .open callbacks
truncate: Fix corruption when plugin changes per-connection size
truncate: Test for safe
2018 Feb 01
6
[nbdkit PATCH v2 0/3] add log, blocksize filters
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
2018 Jan 20
4
[PATCH nbdkit] filters: Add copy-on-write filter.
Eric, you'll probably find the design "interesting" ...
It does work, for me at least.
Rich.
2019 May 16
3
[nbdkit PATCH 0/2] Avoid oddities with files unaligned to granularity
When using a filter that rounds up to alignment boundaries, the tail
bytes of the plugin are difficult to access correctly. Rather than
duplicating lots of code already in the truncate filter, it's easier
to just make the other filters default to rounding down and add doc
links on how to round up instead.
Eric Blake (2):
blocksize: Lift restriction against 0-size file
cache, cow: Round
2018 Mar 08
19
[nbdkit PATCH v3 00/15] Add FUA support to nbdkit
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]
2018 Jan 19
10
[PATCH nbdkit filters-v2 0/5] Introduce filters.
Rebased filters patch. Requires current git master + the locks /
thread model fix
(https://www.redhat.com/archives/libguestfs/2018-January/msg00128.html)
So a few changes here since last time:
The "introduce filters" and "implement filters" patches are
squashed together.
I introduced a concept of .prepare and .finalize. These run before
and after the data serving phase
2018 Jan 22
1
[PATCH nbdkit] filters: Add caching filter.
This adds a cache filter, which works like the COW filter in reverse.
For realistic use it needs a bit more work, especially to add limits
on the size of the cache, a more sensible cache replacement policy,
and perhaps some kind of background worker to write dirty blocks out.
Rich.