Mostly cleaning up some errors and adding some stats for Eric Monson's
class project last fall.

Mostly, before the alloc_writebuf in a vague hope that the yield will
lead to freed memory that will prevent blocking in the alloc_writebuf.

These are drops of the so-called dubious chunks. Dubious chunks are those
which we partially filled, but then we started receiving pieces of another
chunk before completing the first. We mark that first chunk as dubious under
the assumption that the remainder of that chunk got dropped (by us or on
the wire) and we won't be seeing the remaining blocks for some time.

If the decompressor thread had nothing to do, it used to just sleep for
a fixed period (1ms) and check again. If CONDVARS_WORK is set, we now just
sleep on a condvar and wait for the network thread to wake us up when it
finishes filling out a chunk.

It appeared to be before, but wasn't really. The -k option for both client
and server will set the max socketbuf size in KB (NOTE: THIS USED TO BE MB!)
The actual socketbuf size will then be the min of that and what the system
supports.

The client stats now include the sockbuf size of the run.

editing window appear, plus another button to expand that into
a bigger editing modal.

To avoid namespace conflicts (e.g., with libm's "log" function).

It was eating the following newline in some cases, causing the following
line to get concatonated, leading to syntax errors in the file.

I had missed the initiatorgroup option, which is a foreign key into the
authorized initiators table.

Thanks to Kirk for pinning this down so well so I could just fix it!!

Will cause a write error. This would only happen for the final range of
an image created with -f. We now pad out any partial last sector if direct
IO is specified (-f on imageunzip/frisbee) and write that to the file.

If the padding causes any problems in the future, we can always get rid of
it by truncating the file to the correct size when we are done...I think.

we start putting the submap entries into the XML descriptor.

image. Been wanting to do this for a while since the dependency on
copying the contents of the root disk to create an image, has always
been a dubious approach, since there is no consistency over time,
and because it is unclear if the resulting image will boot on a
physical node later (cause of the XEN stuff that is on the disk).

 * bootstrap-filestyle
 * http://dev.tudosobreweb.com.br/bootstrap-filestyle/
 *
 * Copyright (c) 2013 Markus Vinicius da Silva Lima
 * Version 1.0.3
 * Licensed under the MIT license.
 */

To further prevent (or maybe promote) confusion.

If they specify filesystem creation, it can take 5 minutes or longer
depending on the FS type and size. We print a warning about this.

Previously, Linux could do ext* and BSD could do UFS. Now linux can also
RO mount UFS while FreeBSD can RW mount ext[23] and RO mount ext4
(FreeBSD 10 only for ext4). So ext3 would be a good choice if you want your
blockstore available no matter the OS being used.