rbd: zero return code in rbd_dev_image_id()

There is a call in rbd_dev_image_id() to rbd_req_sync_exec()
to get the image id for an image.  Despite the "get_id" class
method only returning 0 on success, I am getting back a positive
value (I think the number of bytes returned with the call).

That may or may not be how rbd_req_sync_exec() is supposed to
behave, but zeroing the return value if successful makes it moot
and makes this path through the code work as desired.

Do the same in rbd_dev_v2_object_prefix().

Signed-off-by: Alex Elder <elder@inktank.com>
rbd: verify rbd image order value

This adds a verification that an rbd image's object order is
within the upper and lower bounds supported by this implementation.

It must be at least 9 (SECTOR_SHIFT), because the Linux bio system
assumes that minimum granularity.

It also must be less than 32 (at the moment anyway) because there
exist spots in the code that store the size of a "segment" (object
backing an rbd image) in a signed int variable, which can be 32 bits
including the sign.  We should be able to relax this limit once
we've verified the code uses 64-bit types where needed.

Note that the CLI tool already limits the order to the range 12-25.

Signed-off-by: Alex Elder <elder@inktank.com>
rbd: simplify rbd_merge_bvec()

I think the rbd merge_bvec function is a little bit harder
to understand than it needs to be.  This was an issue when
a recent btrfs bug led us to question whether the merge
function was working correctly.

The aim of this patch is just to make what it's doing a
bit more obvious than it was before.

Use "seg" rather than "chunk" to indicate the units whose boundaries
we care about we call "segments."

It also adds an extra validation check to rbd_dev_ondisk_valid(),
ensuring the order is at least as big as a sector (a requirement
of the generic bio code).

Signed-off-by: Alex Elder <elder@inktank.com>
btrfs: fix btrfs logical offsets bug

Code from Josef Bacik to fix a btrfs problem.

Signed-off-by: Alex Elder <elder@inktank.com>
rbd: simplify rbd_rq_fn()

When processing a request, rbd_rq_fn() makes clones of the bio's in
the requests's bio chain and submits the results to osd's to be
satisfied.  If a request bio straddles the boundary between objects
backing the rbd image, it must be represented by two cloned bio's,
one for the first part (at the end of one object) and one for the
second (at the beginning of the next object).

This has been handled by a function bio_chain_clone(), which
includes an interface only a mother could love, and which has
been found to have othe problems.

This patch defines two new generic bio functions (one which replaces
bio_chain_clone()) to help out the situation, and then revises
rbd_rq_fn() to make use of them.

First, bio_clone_range() clones a portion of a single bio, starting
at a given offset within a bio and including only as many bytes
as requested.  As a convenience, a request to clone the entire bio
is passed directly to bio_clone().

Second, bio_chain_clone_range() performs a similar function,
producing a chain of cloned bio's covering a sub-range of the
source chain.  No bio_pair structures are used, and if successful
the result will represent exactly the specified range.

Using bio_chain_clone_range() makes bio_rq_fn() a little easier
to understand, because it avoids the need to pass any intermediate
state information between consecutive calls.  By avoiding the need
to track a bio_pair structure, it also eliminates the problem
described here:  http://tracker.newdream.net/issues/2933

Signed-off-by: Alex Elder <elder@inktank.com>