Add refcounting to blockfiles

This will let the superstructures we build on blockfiles pin them open until
they are no longer needed. I.e. we can't create a B-Tree descriptor and then
close the blockfile out from under it.

Signed-off-by: Casey Dahlin <cdahlin@redhat.com>
Declare colormap_allocate static

Signed-off-by: Casey Dahlin <cdahlin@redhat.com>
Change blockfile API

We now use a custom bfsize_t instead of size_t, which is guaranteed to be 64
bits on all platforms. We also have a block_t type which is used when we're
passing block numbers, though it is the same dimensions as bfsize_t.

We then introduce several error constant block numbers at the end of the value
range, so we never need to have a signed bfsize_t or block_t.

Signed-off-by: Casey Dahlin <cdahlin@redhat.com>
Don't map blocks twice

Signed-off-by: Casey Dahlin <cdahlin@redhat.com>
Refcount blockfile mappings

Calling blockfile_map on the same region twice will yield the same pointer, but
now it will also require that unmap be called twice on that region to remove
it.

Signed-off-by: Casey Dahlin <cdahlin@redhat.com>
Update spec

Orders now stop at 3; there is no concept of "higher order values." 3 is
necessarily defined as a catchall. We use the concept of "arity" to explain why
we would separate values into four and only four groups.

Signed-off-by: Casey Dahlin <cdahlin@redhat.com>
Touch ups on spec

We now have a version number, and some minor typos and diction problems have
been fixed.

Signed-off-by: Casey Dahlin <cdahlin@redhat.com>
Add B-Tree implementation

This code implements a B-tree on top of block file blocks. It's compile-tested
only right now, but it needs to be in source control before it gets any
hairier.

Nodes are one block long, and contain key-value pairs. The first key is
ignored since B-trees usually have one fewer key than children, but the first
key still must be the least key, because we store the keys unsorted, which
saves disk syncs and helps us stay atomic, but shifts more load onto the CPU.
Time will tell whether this is the right decision.

Each B-tree has a metadata "head block" which contains, among other things, a
journal. The journal gets slightly less than a block's worth of space
(whatever's left after the B-tree meta data and root pointer). The journal size
bounds how complex a restructuring operation we can perform on the tree, and
thus ultimately the height of the tree. I haven't computed the bound but it
should be large enough. It's format is simple enough: it records changes to the
tree such as adding keys, removing them, merging blocks, etc. When it's time to
commit, we add a checksum trailer and begin executing the changes.

Signed-off-by: Casey Dahlin <cdahlin@redhat.com>