similar to: Re: LZO compression for NBD ?

On Thu, Mar 26, 2020 at 02:34:41PM -0500, Eric Blake wrote: > We're still seeing sporadic failures of 'nbdkit nbd tls=', and I'm > still trying to come up with a root cause fix (it may involve smarter > use of gnutls_bye() in libnbd). In the meantime, here's what we know: > when the hang/failure happens, the 'nbdkit nbd tls=' client process is > stuck in

This is a minimal implementation of an NBD forwarder; it lets us convert between old and newstyle connections (great if a client expects one style but the real server only provides the other), or add TLS safety on top of a server without having to rewrite that server. Right now, the real server is expected to live on a named Unix socket with no encryption, and the transactions are serialized

This is a minimal implementation of an NBD forwarder; it lets us convert between old and newstyle connections (great if a client expects one style but the real server only provides the other), or add TLS safety on top of a server without having to rewrite that server. Right now, the real server is expected to live on a named Unix socket, and the transactions are serialized rather than

We're still seeing sporadic failures of 'nbdkit nbd tls=', and I'm still trying to come up with a root cause fix (it may involve smarter use of gnutls_bye() in libnbd). In the meantime, here's what we know: when the hang/failure happens, the 'nbdkit nbd tls=' client process is stuck in a poll() waiting to see EOF from the server, while the 'nbdkit example1'

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've added lzo compression support for tinc 1.0pre8. Lzo is a very fast compressor (see http://www.oberhumer.com/opensource/lzo/). I've implemented it by using two new compression levels. Compression level 10 is for fast compression using lzo1x-1 algorithm. Compression level 11 is for slow compression using lzo1x-999 algorithm.

In preparation for allowing interleaved response, refactor the nbd forwarder so that writes are still done from the thread handling the original request from the client, but all reads are done by a dedicated reader thread. Control between the two flags is gated by a mutex for storing the transaction information, coupled with a pipe for the reader thread to send the final status back to the

On 11/21/2017 03:21 PM, Richard W.M. Jones wrote: > This works OK on x86_64, but fails on our fast new Amberwing (aarch64) > machine. I've attached the test-suite.log file, but I'm not very sure > what's going wrong from that. > I'll see what I can spot... > FAIL: test-parallel-file.sh > =========================== > > read 1/1 bytes at offset 0 > 1

Hi, I planned to boost my btrfs performance today. here some errors I met: my ''btrfs filesystem show'' result: ~ # btrfs filesystem show failed to read /dev/sr0 Label: none uuid: 9b9aa9d9-760e-445c-a0ab-68e102d9f02e Total devices 1 FS bytes used 36.59GB devid 1 size 49.52GB used 49.52GB path /dev/sda6 Label: none uuid: 559dec06-4fd0-47c1-97b8-cc4fa6153fa0

Hi, On 26.09.2016 09:53, Wouter Verhelst wrote: > On Mon, Sep 26, 2016 at 03:22:52AM +0200, Carl-Daniel Hailfinger wrote: >> Running nbd-tester-client against nbdkit with oldstyle negotiation was fun. >> I managed to segfault nbdkit Side note: I'm going to try and get a backtrace from the nbdkit segfault and submit a bug report there. >> and noticed that

The docs are a lot more useful with a graphic showing how to wire together nbdkit as a bridge from old-to-new. The converse, bridging new-to-old, is best deferred until I add support for the nbd plugin connecting to a TCP socket. It is also worth mentioning use of nbdkit filters (after all, qemu-nbd 4.0 was able to deprecate its --partition option by pointing to 'nbdkit --filter=partition nbd

qemu-nbd defaults to permitting only a single NBD client. Of course, you can run qemu-nbd -t to work around it, but other servers may have similar restrictions, at which point nbdkit's nbd plugin can provide the automatic fanout to multiple clients via a single server link. Note that the shared=true parameter makes the previously-added retry=N parameter more useful, as it is much easier to

* Change the title so it's informative and searchable. * Remove references to the non-libnbd plugin. * Headings for examples. * Correct reference to qemu-nbd(8) man page. * General copy-editing to improve readability. * Change style in places so it matches other manual pages. --- plugins/nbd/nbdkit-nbd-plugin.pod | 192 +++++++++++++++++------------- 1 file changed, 109 insertions(+), 83

* Change the title so it's informative and searchable. * Remove references to the non-libnbd plugin. * Headings for examples. * Correct reference to qemu-nbd(8) man page. * General copy-editing to improve readability. * Change style in places so it matches other manual pages. --- plugins/nbd/nbdkit-nbd-plugin.pod | 192 +++++++++++++++++------------- 1 file changed, 109 insertions(+), 83

I've documented a desire to do this for a while, time to actually follow through and support connecting as a client to a TCP server. Note that it is desirable to support the plugin connecting to an encrypted server over TCP, then exposing the raw data over a local Unix socket; that aspect requires yet more work, left for another day. But even allowing an old-style client to connect to an

On Mon, Sep 26, 2016 at 11:43:42AM +0100, Alex Bligh wrote: > > > On 26 Sep 2016, at 10:21, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> wrote: > > > > Wow, that was quick! Thank you. > > > > I stumbled upon another problem: Apparently nbd-tester-client and nbdkit > > disagree on what constitutes a valid flush request. > >

On Tue, Jul 07, 2020 at 08:17:31AM -0500, Eric Blake wrote: > With new enough libnbd, we already support vsock by virtue of uri=; > however, it's also nice to allow direct exposure of the > nbd_connect_vsock() api. > > Signed-off-by: Eric Blake <eblake@redhat.com> > --- > plugins/nbd/nbdkit-nbd-plugin.pod | 29 +++++++++++--- > plugins/nbd/nbd.c

I'm pleased to announce the release of nbdkit 1.20, a high performance plugin-based Network Block Device (NBD) server. https://en.wikipedia.org/wiki/Network_block_device Key features of nbdkit: * Multithreaded NBD server written in C with good performance. * Minimal dependencies for the basic server. * Liberal license (BSD) allows nbdkit to be linked to proprietary libraries or

(This email is largely me just thinking aloud ... So ideas welcome!) For the RISC-V builders (http://fedora.riscv.rocks) I'm using an NBD disk to host the heavily used /var/lib/mock build directory. This is because the build machines have only SD-cards as local disk and SD is both slow and unreliable. The builders (NBD clients) are set up with an /etc/rc.d/rc.local file which runs these

The NBD spec was recently patched (nbd.git commit 7827f3ae and friends) to require NBD_OPT_GO for baseline interoperability, with the aim of fewer servers and clients falling back to NBD_OPT_EXPORT_NAME. And since nbdkit as server recently started supporting NBD_OPT_GO (commit f7dd9799), our nbd client as plugin should take advantage of it. This patch is a prerequisite to teaching the nbd plugin

NBD — Network Block Device — is a protocol for accessing Block Devices (hard disks and disk-like things) over a Network. nbdkit is a toolkit for creating NBD servers. The key features are: * Multithreaded NBD server written in C with good performance. * Minimal dependencies for the basic server. * Liberal license (BSD) allows nbdkit to be linked to proprietary libraries or included in