This test was causing problems by using dummy pointers to simulate
connections. When calling the cleanup code, these pointers were
thought to be real, and the code attemtped to clean up threads
referenced by those pointers, causing a segfault.
I've reimplemented the test in the ruby acceptance suite.
This ensures the correct number of connected clients is returned when
the status command is issued.
Previously the thread pool would only be cleaned up on a new connection.
In #36 some of the odd errors were due to seeks beyond the end of the
disc. This was because the disc was "specially crafted" to be 25GB + 1
byte, which doesn't fit into the normal 512 byte sectors expected of a
disc. This lead to reads going beyond the end of the disc etc.
If a similarly evil disc is used with `losetup`, it just ignores the
last bytes of the disc that don't fit into 512 chunks. This is what
that patch does, logging an error at the same time.
Previously the proxy would just disconnect when it saw an NBD protocol
error, and retry the operation it was in the middle of.
Additionally, the server needs to return the correct error types when
this happens.
This number is peppered all over the test suite, so changing @blocksize
for everything is not a goer, when we really only need to change it for
one test.
Use a BINARY encoded string when doing read/write comparisons.
This is a bit of a cheat really, but `#read` returns an ASCII encoded
string, where as our ruby generates UTF-8 encoded strings, causing
assertion failures.
Closes#20
See merge request !8
This is a bit of a cheat really, but `#read` returns an ASCII encoded
string, where as our ruby generates UTF-8 encoded strings, causing
assertion failures.
Fixes#20
This commit beefs up the Makefile to do the build, instead of the
Rakefile.
It also removes from the Rakefile the dependency on rake_utils, which
should mean it's ok to build in a schroot.
The files are reorganised to make the Makefile rules more tractable,
although the reorganisation reveals a problem with our current code
organisation.
The problem is that the proxy-specific code transitively depends on the
server code via flexnbd.h, which has a circular dependency on the server
and client structs. This should be broken in a future commit by
separating the flexnbd struct into a shared config struct and
server-specific parts, so that the server code can be moved into
src/server to more accurately show the functional dependencies.
The idea behind this feature was to avoid the client thread in a listen
server getting stuck forever if the mirroring thread in the source died.
However, it breaks any sane implementation of max_Bps in that thread,
and there are lingering concerns over how it might operate under normal
conditions anyway.
Specifically, if iterating over the bitmap takes a long time, or even just
reading the requisite 8MB from the disc in order to send it, then the
5-second timeout could be hit, causing mirroring to fail unnecessarily.
Since the vast majority (something like 94% on boot) are sequential small
reads, and since network latency is a major factor in determining how fast the
exposed device appears to the client, it makes sense for us to try to minimise
the number of network requests where we safely can.
This patch implements the simplest possible read cache in flexnbd-proxy. When
it receives a read request, if it's a small request then flexnbd-proxy will
double the length of data requested. On receiving the data from the upstream
server, flexnbd-proxy will return the first half to the downstream as normal,
and stash the second half in a buffer. If the very next request is a read, and
the offset and length match those of what we have stored, that second request
will be satisfied from the buffer without going out over the network.
The cache is invalidated by any non-read request, or by a disconnection.
