krbd: write path (layering)
#2 Updated by Alex Elder over 7 years ago
I did a little research on this before starting on the write
path. This work will require the kernel rbd client, the kernel
osd client, and the kernel messenger code to support osd requests
that contain multiple osd operations. There are (or were--I've
since cleaned this up) some areas where it appears multiple ops
are supported, but this support is by no means complete.
In fact, the messenger explicitly assumes that a single message
(to anything, but in this case to an osd) will contain either a
single page vector of data payload, or a single list of Linux bio
structures of data payload. What we really need is to have--in
the osd request case--each op in a request be able to supply is
own data payload. This will require some significant rework in
the messenger code.
Specifically, when a write request to an image targets an object
that doesn't exist, the rbd client needs to issue a read request
to the parent for the data for the complete target object. Once
that is in hand, the client needs to send that (read) object data
and the new (to-be-written) object data in two ops that must
reside in a single osd request. The messenger right now will not
#6 Updated by Alex Elder almost 7 years ago
In order to distinguish this issue from
call this one complete when I have the
existence check for a target object of a
layered write implemented.
That is, before issuing a write request, if
we don't know that the target object exists
a stat for the object will be done first to
determine whether it does.
At that point we'll proceed as if it were a
normal object though. This is in conflict with
final functionality but that stuff won't be
enabled until the LAYERING feature flag is
#7 Updated by Alex Elder almost 7 years ago
- Status changed from In Progress to Fix Under Review
I have posted the following for review:
I've broken these patches into three groups.
The first two are sort of cleanup from prior patches.
The next one adds support for simple ops that contain
a single data item, which I've termed "raw data."
The next two are some more refinements but they
were done intentionally to prepare for the last
The sixth puts in place flags on object requests
that allow the last patch to determine whether it
needs to issue a STAT call for a target object
before doing a layered write request.
The layered write request ends up being fairly
simple. Existence flags are recorded for the
target of object requests. If it is unknown
whether the object exists, a new standalone
object request is created to do a STAT on the
object. The result (success or ENOENT) is
recorded in a flag in the original request,
at which point the original request is
This is the first step in doing layered writes.
[PATCH 1/7] libceph: kill off osd data write_request parameters
[PATCH 2/7] libceph: clean up osd data field access functions
[PATCH 3/7] libceph: support raw data requests
[PATCH 4/7] rbd: adjust image object request ref counting
[PATCH 5/7] rbd: always check IMG_DATA flag
[PATCH 6/7] rbd: add target object existence flags
[PATCH 7/7] rbd: issue stat request before layered write
#8 Updated by Alex Elder almost 7 years ago
- Status changed from Fix Under Review to Resolved
The following have been committed to the "testing" branch
of the ceph-client git repository:
a065a13 libceph: kill off osd data write_request parameters
07e9448 libceph: clean up osd data field access functions
3dc3868 libceph: support raw data requests
7a8762c rbd: adjust image object request ref counting
9799b86 rbd: always check IMG_DATA flag
bf87d7b rbd: add target object existence flags
2f40fd4 rbd: issue stat request before layered write