To-do list for nbdkit
======================================================================

General ideas for improvements
------------------------------

* Listen on specific interfaces or protocols (eg. only IPv6).

* syslog? journal?

* Performance - measure and improve it.

* Exit on last connection (the default behaviour of qemu-nbd unless
  you use -t).

* Limit number of incoming connections (like qemu-nbd -e).

* For parallel plugins, only create threads on demand from parallel
  client requests, rather than pre-creating all threads at connection
  time, up to the thread pool size limit.  Of course, once created, a
  thread is reused as possible until the connection closes.

* Async callbacks.  The current parallel support requires one thread
  per pending message; a solution with fewer threads would split
  low-level code between request and response, where the callback has
  to inform nbdkit when the response is ready:
  https://www.redhat.com/archives/libguestfs/2018-January/msg00149.html

* More NBD protocol features. Qemu has implemented Structured Replies,
  which allows for more efficient serving of sparse files.  Also in
  the upstream pipeline: proposals for block status and online resize.

* Add a callback to let plugins request minimum alignment for the
  buffer to pread/pwrite; useful for a plugin utilizing O_DIRECT or
  other situation where pre-aligned buffers are more efficient.
  Ideally, a blocksize filter would honor strict alignment below and
  advertise loose alignment above; all other filters (particularly
  ones like offset) can fail to initialize if they can't guarantee
  strict alignment and don't want to deal with bounce buffers.

* Add per-connection caching of .can_FOO callbacks (we already have
  some: .can_write is only called once, but .can_fua is called on
  every request with the FUA flag set).

* Test that zero-length read/write requests behave correctly
  (NBD protocol says they are unspecified).

Suggestions for plugins
-----------------------

* XVA files
  https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg02971.html
  is a partial solution but it needs cleaning up.

* glance

* cinder

Note: qemu supports other formats such as libssh, libnfs, iscsi,
gluster and ceph/rbd, and while similar plugins could be written for
nbdkit there is no compelling reason unless the result is better than
qemu-nbd.  For the majority of users it would be better if they were
directed to qemu-nbd for these use cases.

nbd plugin could use enhancements:

* FUA passthrough, rather than extra FLUSH calls.  For this, .can_fua
  must be exposed to plugins (not just filters), and needs to be
  tri-state rather than just bool.

* Enable client-side TLS (right now, the nbd plugin allows us to
  support an encrypted client connecting to a plain server; but we
  would need TLS to support a plain client connecting to an encrypted
  server).

* Support for connecting to a server over IP rather than just Unix
  sockets.

Suggestions for filters
-----------------------

* tar plugin should really be a filter

* xz plugin should really be a filter

* gzip plugin should really be a filter

* injecting artificial errors or otherwise masking plugin features
  for testing clients (see 'nozero' and 'fua' filters for examples)

nbdkit-cache-filter needs considerable work:

* allow the user to limit the total size of the cache

* handle ENOSPC errors

* implement some cache replacement policies

* some sort of background task or thread to write out dirty blocks

Composing nbdkit
----------------

Filters allow certain types of composition, but others would not be
possible, for example RAIDing over multiple nbd sources.  Because the
plugin API limits us to loading a single plugin to the server, the
best way to do this (and the most robust) is to compose multiple
nbdkit processes.

The nbd plugin (plugins/nbd) already contains an NBD client, so we
could factor this client out and make it available to other plugins to
use.
