libnbd truncating 4G extents resulting in unaligned reads

If a plugin has a hole which is exactly 4G (4294967296 bytes) in size, and the plugin cannot handle non-aligned requests, then nbdinfo may issue a non-aligned request causing a failure:

$ nbdkit data '@4294967296 1' --run 'nbdinfo --map --totals "$uri"' \
    --filter=blocksize-policy blocksize-error-policy=error blocksize-minimum=512
nbdinfo: nbd_block_status_64: request is unaligned: Invalid argument

If you enable debugging you'll find that nbdinfo sees a 4294967295 (4G-1) hole. It then adjusts the offset to 4294967295 and issues the next nbd_block_status_64 request, which fails because of the blocksize policy filter rejecting the unaligned request.

I added debugging on the nbdkit side, and I think it's sending a 4G extent? If it's being truncated on the nbdkit side then this would be an nbdkit bug instead. (I'm not very familiar with how we extended the block status command to handle 64 bit lengths.)

This is a simplified example from a real bug in our virt-v2v tool. In that tool we have a plugin which only accepts sector-aligned requests, and rejects anything which is not aligned. (The blocksize filter may be used to work around that, but that covers up the underlying bug).

@ebblake @crobinso