NBD userland road map

Why?

When Pavel Machek created the Network Block Device, he wrote an nbd-server and an nbd-client in a pretty hackish way; they appear to not have received much design or thought.

As a result, the nbd userland tools, although they do work, are not very fast or flexible, and, because of the low code quality, are a pain to maintain. This is an issue that needs addressing, and has done so for quite a while already; but it's a long and tedious job, one that could use some help.

What I specifically do not address in this document is the kernel side of things. That is a completely distinct problem, which I am not involved with; for issues regarding the kernel nbd module, please contact the kernel maintainer.

In this document, I will start by outlining the current state of the nbd utilities, explain where they could be improved, and explain how I'll tackle different things. The road map will set goals as version numbers, not as dates; this is both because the time it will take to perform some task depends highly on the amount of spare time and help I get, and because, although I do have a general idea on what needs to be done, I am not so sure about the specifics, nor am I very sure to what extent some tasks need to be performed.

What follows is the road map, starting with...

Version 2.7: fixup, cleanup.

This version will feature:

This version was released on 2004-05-17, well on time for the Sarge release.

Version 2.8: code beauty

This version will feature:

This version was released on 2005-10-25.

Version 2.9: flexibility

This version will feature:

This version was released on 2006-11-01

Version 2.10: performance

This version will implement some way to improve performance. Possible options are:

These are just possibilities I've come up with until now. More might be added, and some might be dropped depending on what their actual performance impact is. Will have to come up with some benchmark, I presume.

Version 3.0: "new version"

Once 2.10 is ready and considered stable, nbd-server will be labeled 3.0. Hopefully, we'll be able to maintain it a lot better, then. It will also include the following:

Version numbering

Versions will be numbered as "x.y.z", with:

In other words, x.y.z will have less bugs than x.y.(z-1), while x.(y+1).0 might introduce some new ones. At least, that's the idea.