| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| | |
|
| |
|
|
| |
No reply was ever given for unhandled requests. Return EACCES.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Also turn into normal POST with urlencoded payload.
|
| |
|
|
|
| |
curl_easy_header was introduced in 7.83, so not even available
in Ubuntu 22.04. Switch to manual header parsing.
|
| |
|
|
|
|
|
|
| |
- Add support for aborting session and further uploads via SIGQUIT
- Make API versioned
- Change it to "uuid" everywhere instead of a mix of uuid and guid
- Server can now tell us to wait with further uploads
- merge request is now urlencoded POST instead of mime data
|
| |
|
|
|
| |
Add a version to the URL, rest can be configured dynamically by -C
as it's a simple prefix.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't allocate a data cluster in data file for empty l2 entries when
resizing the image file.
Calculating l2 offset in metadata file was broken and overlapping l1.
Delete unneeded entries from cow struct.
Rename a few more variables.
Fix a few possible race conditions.
Only upload modified blocks from cluster.
Simplify cow_write() function by handling misaligned start/end first.
Try to also simplify cow_read() a bit.
TODO: Documentation, update the cow merger service.
|
| |
|
|
|
|
|
|
|
| |
- Use the term "cluster" for a group of dnbd3-blocks instead of also
calling them blocks.
- Use term "table" instead of "array" for the L1 and L2 tables.
- Use term "index" instead of "offset" when addressing those tables
- Fix a few logic bugs, use-after-free
- Add TODOs for parts that need better comments
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
5ms was apparently way too low and lead to frequent switch-aways from
the local dnbd3-server on heavy load during bootup.
|
| | |
|
| | |
|
| |
|
|
|
| |
Co-authored-by: Jonathan Bauer <jonathan.bauer@rz.uni-freiburg.de>
Co-authored-by: Manuel Messner <mm@skelett.io>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, we only did the actual socket connect in a
concurrent matter. Once a connection was successfully
established, we did a blocking handshake on the protocol
level. If the server war particularly slow, this was bad
as we would not try other servers until after this.
Throw out the previous non-blocking async connect logic,
switching to a multi-threaded approach, that spawns one
thread per host/ip, offset by 200ms, until one of
the attempts succeeds.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Bringing up a proxy that has been offline for some time will trigger
lots of loads and replication on other proxies when booting up again.
Just wait until a client actually needs an image before establishing
an uplink connection.
|
| | |
|
| | |
|
| |
|
|
| |
Even if we didn't switch because we already use the requested server.
|
| |
|
|
|
|
|
| |
If we switch to a different server when we only have something in
the send list but nothing in the recv list, the send worker would
not have gotten invoked. Now we unconditionally trigger the send
worker when asked to re-queue any pending requests.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using workqueues frees us from having to manage the lifecycle
of three dedicated threads. Discovery (alt server checks) and
sending keepalive packets is now done using work on the
power efficient system queue. Sending and receiving happens
via dedicated work queues with higher priority.
blk-mq has also been around for quite a while in the kernel,
so switching to it doesn't hurt backwards compatibility.
As the code is now refactored to work more as blk-mq is designed,
backwards compatibility even improved while at the same time
freeing us from an arsenal of macros that were required to make
the blk-mq port look and feel like the old implementation.
For example, the code now compiles on CentOS 7 with kernel 3.10
without requiring special macros to detect the heavily modified
RedHat kernel with all its backported features.
A few other design limitations have been rectified along the way,
e.g. switching to another server now doesn't internally disconnect
from the current one first, which theoretically could lead to a
non-working setup, if the new server isn't reachable and then -
because of some transient network error - switching back also
fails. As the discover-thread was torn down from the disconnect
call, the connection would also not repair itself eventually.
we now establish the new connection in parallel to the old one,
and only if that succeeds do we replace the old one with it,
similar to how the automatic alt-server switch already does it.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This spams scary red errors to dmesg when really an unreachable alt
server isn't that much of a deal during normal operation. Change the
log level to debug instead.
Might even consider not printing anything at all.
|