Ceph » rbd

I'm about to mark bug 3417 as a duplicate of this.
I'm putting this bit of info from there here first.

Work on this really started in November 2012.

In October there were a number of cleanup tasks we agreed
should get done first, and the the first "real" task was
to implement fetching information about an image's parent
if present. That work was completed (but from what I can
tell had no issue assigned to it).

After several false starts in November attempting to
implement the read path (redirecting read requests with
ENOENT responses to the parent image) I found the existing
code and data structures would not very easily support
this different source of I/O requests to OSD's. After
some discussion, we agreed that doing a sort of
reimplementation was a reasonable course forward.

That work was nearly complete in November, but numerous
other things have preempted further progress. Specifically,
I have been working on expanding xfstests coverage over rbd,
setting up, running, and recovering from the failures hit
when network connection failures are in injected.

I'll return to this task as soon as possible. I had hoped
to have this completed in November, now I'm hopeful for
the end of December.

This task depends on the completion of the following others
before it can be completed:
3741 krbd: rework request tracking code
And that currently depends on:
3754 krbd: use new request tracking code for notify ack
3755 krbd: use new request tracking code for sync object operations

This work is close to complete, in that I have shown
that a lot of functionality seems to work correctly.

I was never able to do the thorough testing I wanted
to though. This code has also had to be reworked a
little bit as I've done some development on the write
path.

At this point I'm not sure how much more effort this
will require to really complete, it depends on whether
testing shows any surprising problems.

I have the read path code mostly working now. The problem was
that an object request that gets redirected to a parent image
needs to get its byte transfer count updated. That wasn't
happening. I now have a image request transfer count that
gets copied into the object request that submitted the
parent image request.

So all that seems to work but unfortunately the mapping
of a clone of a clone case is still returning zero bytes.
(Could be a similar problem, I don't know at this point.)

More looking at that in detail in the morning.

I also hope to get get my layered read test script
hammered out so I can use it.

I have identified two problems that I was hitting.

First, it was not possible for me to map a format 2 rbd image,
because there is a new feature RBD_FEATURE_STRIPINGV2 that
is marked as incompatible by the osd server (i.e., if the
client doesn't support it, it claims they can't interact).

So I'm addressing that by pretending I support that feature
(but I think it shouldn't be mandatory unless a particular
image uses the feature).

Second, the rbd CLI was exiting with status 0 (success)
even though the request to map a version 2 image failed.
I opened a new bug for that:
http://tracker.ceph.com/issues/4707

OK, that feature bit was my problem. I am now able to
successfully map a version 2 image.

Having done that I created a clone and read from it,
and it my initial simple tests produced the same
data as the original. I'll try my big test on it
shortly, but first I'm going to try a clone-of-a-clone.

Sweet, clone of snap of clone of snap of image produced the
same result as the original image. Finally back to where
I was when I last got the read path working...

Fuckin' A. My test passed with the clone too.
(It should, but I wasn't sure until I ran it.)

Double fuckin' A. (Fuckin' double-A?)

I just updated my test to validate snapshot-of-clone and
clone-of-snapshot of clone and that worked fine too.

I'm about to check in my updated test. Note that the only
thing this is doing is verifying that the read data matches
the data found in the original image.

It would be good to validate that data written to a clone
at a given offset is read back correctly. For example:
write 16MB at offset 0 in original
snapshot original
clone original
--> all three when mapped should produce the same
data when reading any offset
write 4K at offset 4MB in the clone
--> original and snapshot should all still be
identical
--> clone should be identical for first 4MB,
different for 2nd 4MB, identical beyond 8MB

I sort of just did this and it seems to work...