I'd be remiss if I didn't enhance the testsuite to exercise the
nbd plugin (after all, the best way to make sure something doesn't
regress is to cover it in the testsuite). Borrows heavily from
test-file, with the main difference being that I wrap three nbdkit
processes instead of one.
Signed-off
The obvious way to test the nbd plugin is to wrap yet another
nbdkit server. The testsuite already has nice cleanup of an
nbdkit server, which we want to reuse while multiple servers
are running. So rework global variables to instead belong to
a struct which is allocated per invocation, with the
To avoid bitrot, any new feature needs testsuite coverage ;)
Still to come: once I get my work on parallel nbd finished,
I will add a test-parallel-nbd.sh that closely mirrors what
my other series added in test-parallel-file.sh.
If desired, it might be a fun exercise to tweak test-nbd into
using
I did something different, that will build a raw image directly from a
xenserver export, on the fly.
Compared the resulting file (via MD5) with xenmygrate.py and there is a match.
Currently, this is the faster way to convert a XenServer image to a
raw file. Don't need to wait
for export, tar extra
Finish plumbing up everything we will need to process multiple
client requests in parallel after handshake is complete. Since
status is now global, and properly protected by a mutex, all
of the threads will eventually quit as soon as any of them
notices EOF or nbdkit detects a signal.
For ease of
In preparation for parallel processing, we need to be sure that
two threads belonging to the same connection cannot interleave
their I/O except at message boundaries. Add a mutex around
all reads and writes that must occur as a group (for now, there
is no contention for either mutex).
This commit
Once more per-connection threads are introduced for parallel
plugins, we run a much higher risk of the scheduler causing a
hang during test-socket-activation. The hang is caused by
waiting for a second new client in accept_incoming_connections()
even though the test sent a SIGTERM after the first
We have a lot of nested conditionals controlling which tests to
run; I'm about to add more, and it's easier to do correctly if
we exploit automake's ability to warn us about improper nesting
by annotating which 'if' each 'endif' belongs to.
Signed-off-by: Eric Blake
---
tests/Makefile.am | 26 ++
Add a new macro that lets us easily code a mutex cleanup no
matter how we leave a scope, which relies on the gcc/clang
extension of __attribute__((cleanup)). Note that there is
no semi-safe fallback possible to unlock a mutex once we rely
on cleanup semantics: eliding the attribute would deadlock,
Once we have multiple threads during parallel processing, we need
to be sure that any I/O error flagged by one thread prevents the
next thread from attempting I/O. Although we already have a
separate lock for reads and writes, it's easier if status is
shared by both actions, which needs yet anothe
Codify the testing procedure mentioned during the addition of --threads
into a full-blown member of 'make check'. With the delay values I
chose, the test requires at least 5 seconds to complete; I don't know
if it is worth trying to fine-tune it to run faster while still being
robust in the presen
I've posted some of these patches or ideas before; but now I'm
confident enough with the series that it should be ready to push;
at any rate, I can now run test-socket-activation in a tight loop
without triggering any crashes or hangs.
With this in place, I'm going back to work on making the nbd
f
It's finally time to implement one of the TODO items: we want to
support a thread pool of parallel readers from the client, in
order to allow multiple in-flight operations with potential
out-of-order completion. We also need at least one plugin that
supports parallel processing for testing the opt
On Thu, Nov 16, 2017 at 06:00:54PM +, Richard W.M. Jones wrote:
> On Thu, Nov 16, 2017 at 05:30:48PM +, Stefan Hajnoczi wrote:
> > On Thu, Nov 16, 2017 at 3:10 PM, Richard W.M. Jones
> > wrote:
> > > Both local filesystems, but on different SATA devices.
> >
> > Okay. I'm curious what t
14 matches
Mail list logo
