TODO

   1 To-do list for nbdkit
   2 ======================================================================
   3
   4 General ideas for improvements
   5 ------------------------------
   6
   7 * Listen on specific interfaces or protocols (eg. only IPv6).
   8
   9 * Performance - measure and improve it.
  10
  11 * Exit on last connection (the default behaviour of qemu-nbd unless
  12   you use -t).
  13
  14 * Limit number of incoming connections (like qemu-nbd -e).
  15
  16 * For parallel plugins, only create threads on demand from parallel
  17   client requests, rather than pre-creating all threads at connection
  18   time, up to the thread pool size limit.  Of course, once created, a
  19   thread is reused as possible until the connection closes.
  20
  21 * Async callbacks.  The current parallel support requires one thread
  22   per pending message; a solution with fewer threads would split
  23   low-level code between request and response, where the callback has
  24   to inform nbdkit when the response is ready:
  25   https://www.redhat.com/archives/libguestfs/2018-January/msg00149.html
  26
  27 * More NBD protocol features.  The only currently missing features are
  28   structured replies for sparse reads, and online resize.
  29
  30 * Add a callback to let plugins request minimum alignment for the
  31   buffer to pread/pwrite; useful for a plugin utilizing O_DIRECT or
  32   other situation where pre-aligned buffers are more efficient.
  33   Ideally, a blocksize filter would honor strict alignment below and
  34   advertise loose alignment above; all other filters (particularly
  35   ones like offset) can fail to initialize if they can't guarantee
  36   strict alignment and don't want to deal with bounce buffers.
  37
  38 * Add per-connection caching of .can_FOO callbacks (we already have
  39   some: .can_write is only called once, but .can_fua is called on
  40   every request with the FUA flag set).
  41
  42 * Test that zero-length read/write/extents requests behave sanely
  43   (NBD protocol says they are unspecified).
  44
  45 * If a client negotiates structured replies, and issues a read/extents
  46   call that exceeds EOF (qemu 3.1 is one such client, when nbdkit
  47   serves non-sector-aligned images), return the valid answer for the
  48   subset of the request in range and then NBD_REPLY_TYPE_ERROR_OFFSET
  49   for the tail, rather than erroring the entire request.
  50
  51 * Test and document how to run nbdkit from inetd and xinetd in
  52   nbdkit-service(1).
  53
  54 * Validate that requests which are forwarded by filters are not out of
  55   range.  This is harder than it looks because filters don't "know"
  56   the size of the layer below (unless they call .get_size, but that
  57   might be expensive).  This gets particularly tricky if you assume
  58   that .get_size cannot be cached and/or might change per-connection,
  59   although the rest of nbdkit doesn't behave well in that case either.
  60
  61 * Similarly validate the filters don't forward write requests to
  62   read-only plugins.
  63
  64 * Audit the code base to get rid of strerror() usage (the function is
  65   not thread-safe); however, using geterror_r() can be tricky as it
  66   has a different signature in glibc than in POSIX.
  67
  68 * Teach nbdkit_error() to have smart newline appending (for existing
  69   inconsistent clients), while fixing internal uses to omit the
  70   newline. Commit ef4f72ef has some ideas on smart newlines, but that
  71   should probably be factored into a utility function.
  72
  73 * We may need a way to lock nbdkit into memory and adjust the OOM
  74   killer score.  See this LKML discussion:
  75   https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1933394.html
  76   and also look at the implementation of the -swap option in
  77   nbd-client.
  78
  79 Suggestions for plugins
  80 -----------------------
  81
  82 Note: qemu supports other formats such as libnfs, iscsi, gluster and
  83 ceph/rbd, and while similar plugins could be written for nbdkit there
  84 is no compelling reason unless the result is better than qemu-nbd.
  85 For the majority of users it would be better if they were directed to
  86 qemu-nbd for these use cases.
  87
  88 * XVA files
  89
  90   https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg02971.html
  91   is a partial solution but it needs cleaning up.
  92
  93 nbdkit-floppy-plugin:
  94
  95 * Add boot sector support.  In theory this is easy (eg. using
  96   SYSLINUX), but the practical reality of making a fully bootable
  97   floppy is rather more complex.
  98
  99 * Add multiple dir merging.
 100
 101 nbdkit-linuxdisk-plugin:
 102
 103 * Add multiple dir merging (in e2fsprogs mke2fs).
 104
 105 Suggestions for filters
 106 -----------------------
 107
 108 * tar plugin should really be a filter
 109
 110 * gzip plugin should really be a filter
 111
 112 * libarchive could be used to implement a general tar/zip filter
 113
 114 * LUKS encrypt/decrypt filter, bonus points if compatible with qemu
 115   LUKS-encrypted disk images
 116
 117 * masking plugin features for testing clients (see 'nozero' and 'fua'
 118   filters for examples)
 119
 120 * nbdkit-cache-filter should handle ENOSPC errors automatically by
 121   reclaiming blocks from the cache
 122
 123 nbdkit-rate-filter:
 124
 125 * allow other kinds of traffic shaping such as VBR
 126
 127 * limit traffic per client (ie. per IP address)
 128
 129 * split large requests to avoid long, lumpy sleeps when request size
 130   is much larger than rate limit
 131
 132 Filters for security
 133 --------------------
 134
 135 Things like blacklisting or whitelisting IP addresses can be done
 136 using external wrappers (TCP wrappers, systemd).
 137
 138 However it might be nice to have a configurable filter for preventing
 139 valid but not sensible requests.  The server already filters invalid
 140 requests.  This would be like seccomp, and could be implemented using
 141 an eBPF-based parser.  Unfortunately actual eBPF is difficult to use
 142 for userspace processes.  The "standard" isn't solidly defined - the
 143 Linux kernel implementation is the standard - and Linux has by far the
 144 best implementation, particularly around bytecode verification and
 145 JITting.  There is a userspace VM (ubpf) but it has very limited
 146 capabilities compared to Linux.
 147
 148 Composing nbdkit
 149 ----------------
 150
 151 Filters allow certain types of composition, but others would not be
 152 possible, for example RAIDing over multiple nbd sources.  Because the
 153 plugin API limits us to loading a single plugin to the server, the
 154 best way to do this (and the most robust) is to compose multiple
 155 nbdkit processes.  Perhaps libnbd will prove useful for this purpose.
 156
 157 Build-related
 158 -------------
 159
 160 * Figure out how to get 'make distcheck' working. VPATH builds are
 161   working, but various pkg-config results that try to stick
 162   bash-completion and ocaml add-ons into their system-wide home do
 163   not play nicely with --prefix builds for a non-root user.
 164
 165 * Port to Windows.
 166
 167 Rust plugins
 168 ------------
 169
 170 * Consider supporting a more idiomatic style for writing Rust plugins.
 171
 172 * Better documentation.
 173
 174 * Add tests.
 175
 176 * There is no attempt to ‘make install’ or otherwise package the
 177   crate.  Since it looks as if Rust code is normally distributed as
 178   source it's not clear what that would even mean.
 179
 180 V3 plugin protocol
 181 ------------------
 182
 183 From time to time we may update the plugin protocol.  This section
 184 collects ideas for things which might be fixed in the next version of
 185 the protocol.
 186
 187 Note that we keep the old protocol(s) around so that source
 188 compatibility is retained.  Plugins must opt in to the new protocol
 189 using ‘#define NBDKIT_API_VERSION <version>’.
 190
 191 * All methods taking a ‘count’ field should be uint64_t (instead of
 192   uint32_t).  Although the NBD protocol does not support 64 bit
 193   lengths, it might do in future.
 194
 195 * pread could be changed to allow it to support Structured Replies
 196   (SRs).  This could mean allowing it to return partial data, holes,
 197   zeroes, etc.  For a client that negotiates SR coupled with a plugin
 198   that supports .extents, the v2 protocol would allow us to at least
 199   synthesize NBD_REPLY_TYPE_OFFSET_HOLE for less network traffic, even
 200   though the plugin will still have to fully populate the .pread
 201   buffer; the v3 protocol should make sparse reads more direct.
 202
 203 * Parameters should be systematized so that they aren't just (key,
 204   value) strings.  nbdkit should know the possible keys for the plugin
 205   and filters, and the type of the values, and both check and parse
 206   them for the plugin.