search for: cbdkit_async_repli

Hi, We've been using a modified nbdkit (ours is cbdkit internally) for about half a year now and since you guys appear to be working on a next version of the API I wanted to go over some of the limitations we hit with nbdkit that we think others may also hit for consideration into the batch of changes you are making to the api. About Us: Our primary use for nbdkit is to facilitate a disk

Our cbdkit was branched from 1.1.12 with some patches from 1.1.13 added as well. The project has morphed significantly enough that a direct diff or merging between the two would not be feasible. Even the structure of the project directory and build has been changed to be in line with our other internal projects. I have uploaded the entire cbdkit source to our github at

On 01/19/2018 10:56 AM, Shaun McDowell wrote: > Limitation: The kernel will (with today's default settings) typically be > willing to send up to 128 requests of 128kB size to the driver in parallel. > We wanted to support 128 parallel read operations on different areas of the > disk without requiring 128 separate threads and connections for the driver. > Right now in nbdkit

A combination of the work that both Rich and I have been doing lately, where filters use only the new API with flags on every command that the client can send over the wire (we can then add support for more flags in nbdkit without having to add new callbacks, as NBD adds more flags upstream). Eric Blake (4): protocol: Split flags from cmd field in requests backend: Pass flags argument through