Version 1.15.1.
[nbdkit/ericb.git] / TODO
blob49b60b19d6c90b34f4f9e80810e985982f35441b
1 To-do list for nbdkit
2 ======================================================================
4 General ideas for improvements
5 ------------------------------
7 * Listen on specific interfaces or protocols (eg. only IPv6).
9 * Performance - measure and improve it.
11 * Exit on last connection (the default behaviour of qemu-nbd unless
12   you use -t).
14 * Limit number of incoming connections (like qemu-nbd -e).
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.
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
27 * More NBD protocol features.  The only currently missing features are
28   structured replies for sparse reads, and online resize.
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.
38 * Test that zero-length read/write/extents requests behave sanely
39   (NBD protocol says they are unspecified).
41 * If a client negotiates structured replies, and issues a read/extents
42   call that exceeds EOF (qemu 3.1 is one such client, when nbdkit
43   serves non-sector-aligned images), return the valid answer for the
44   subset of the request in range and then NBD_REPLY_TYPE_ERROR_OFFSET
45   for the tail, rather than erroring the entire request.
47 * Test and document how to run nbdkit from inetd and xinetd in
48   nbdkit-service(1).
50 * Audit the code base to get rid of strerror() usage (the function is
51   not thread-safe); however, using geterror_r() can be tricky as it
52   has a different signature in glibc than in POSIX.
54 * Teach nbdkit_error() to have smart newline appending (for existing
55   inconsistent clients), while fixing internal uses to omit the
56   newline. Commit ef4f72ef has some ideas on smart newlines, but that
57   should probably be factored into a utility function.
59 * We may need a way to lock nbdkit into memory and adjust the OOM
60   killer score.  See this LKML discussion:
61   https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1933394.html
62   and also look at the implementation of the -swap option in
63   nbd-client.
65 Suggestions for plugins
66 -----------------------
68 Note: qemu supports other formats such as libnfs, iscsi, gluster and
69 ceph/rbd, and while similar plugins could be written for nbdkit there
70 is no compelling reason unless the result is better than qemu-nbd.
71 For the majority of users it would be better if they were directed to
72 qemu-nbd for these use cases.
74 * XVA files
76   https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg02971.html
77   is a partial solution but it needs cleaning up.
79 nbdkit-floppy-plugin:
81 * Add boot sector support.  In theory this is easy (eg. using
82   SYSLINUX), but the practical reality of making a fully bootable
83   floppy is rather more complex.
85 * Add multiple dir merging.
87 nbdkit-linuxdisk-plugin:
89 * Add multiple dir merging (in e2fsprogs mke2fs).
91 Suggestions for filters
92 -----------------------
94 * tar plugin should really be a filter
96 * gzip plugin should really be a filter
98 * libarchive could be used to implement a general tar/zip filter
100 * LUKS encrypt/decrypt filter, bonus points if compatible with qemu
101   LUKS-encrypted disk images
103 * masking plugin features for testing clients (see 'nozero' and 'fua'
104   filters for examples)
106 * nbdkit-cache-filter should handle ENOSPC errors automatically by
107   reclaiming blocks from the cache
109 nbdkit-rate-filter:
111 * allow other kinds of traffic shaping such as VBR
113 * limit traffic per client (ie. per IP address)
115 * split large requests to avoid long, lumpy sleeps when request size
116   is much larger than rate limit
118 Filters for security
119 --------------------
121 Things like blacklisting or whitelisting IP addresses can be done
122 using external wrappers (TCP wrappers, systemd).
124 However it might be nice to have a configurable filter for preventing
125 valid but not sensible requests.  The server already filters invalid
126 requests.  This would be like seccomp, and could be implemented using
127 an eBPF-based parser.  Unfortunately actual eBPF is difficult to use
128 for userspace processes.  The "standard" isn't solidly defined - the
129 Linux kernel implementation is the standard - and Linux has by far the
130 best implementation, particularly around bytecode verification and
131 JITting.  There is a userspace VM (ubpf) but it has very limited
132 capabilities compared to Linux.
134 Composing nbdkit
135 ----------------
137 Filters allow certain types of composition, but others would not be
138 possible, for example RAIDing over multiple nbd sources.  Because the
139 plugin API limits us to loading a single plugin to the server, the
140 best way to do this (and the most robust) is to compose multiple
141 nbdkit processes.  Perhaps libnbd will prove useful for this purpose.
143 Build-related
144 -------------
146 * Figure out how to get 'make distcheck' working. VPATH builds are
147   working, but various pkg-config results that try to stick
148   bash-completion and ocaml add-ons into their system-wide home do
149   not play nicely with --prefix builds for a non-root user.
151 * Port to Windows.
153 Rust plugins
154 ------------
156 * Consider supporting a more idiomatic style for writing Rust plugins.
158 * Better documentation.
160 * Add tests.
162 * There is no attempt to ‘make install’ or otherwise package the
163   crate.  Since it looks as if Rust code is normally distributed as
164   source it's not clear what that would even mean.
166 V3 plugin protocol
167 ------------------
169 From time to time we may update the plugin protocol.  This section
170 collects ideas for things which might be fixed in the next version of
171 the protocol.
173 Note that we keep the old protocol(s) around so that source
174 compatibility is retained.  Plugins must opt in to the new protocol
175 using ‘#define NBDKIT_API_VERSION <version>’.
177 * All methods taking a ‘count’ field should be uint64_t (instead of
178   uint32_t).  Although the NBD protocol does not support 64 bit
179   lengths, it might do in future.
181 * pread could be changed to allow it to support Structured Replies
182   (SRs).  This could mean allowing it to return partial data, holes,
183   zeroes, etc.  For a client that negotiates SR coupled with a plugin
184   that supports .extents, the v2 protocol would allow us to at least
185   synthesize NBD_REPLY_TYPE_OFFSET_HOLE for less network traffic, even
186   though the plugin will still have to fully populate the .pread
187   buffer; the v3 protocol should make sparse reads more direct.
189 * Parameters should be systematized so that they aren't just (key,
190   value) strings.  nbdkit should know the possible keys for the plugin
191   and filters, and the type of the values, and both check and parse
192   them for the plugin.