Feature #2851: krbd: RBD layering support
krbd: write path
verify the target object exists in write requests. if we fail with ENOENT, trigger a copy-up.
#1 Updated by Alex Elder about 11 years ago
I'm not sure what "guard writes" is supposed to mean.
But I'm going to interpret it as simply implementing the
write path for layered images.
That means checking for the existence of the target object
for a request, and if it does not exist, fetching full
osd object data from the parent image and then writing that,
along with the original write data, to the target image.
#2 Updated by Alex Elder about 11 years ago
I'm about to mark bug 3418 as a duplicate of this one.
I'm adding the following from that bug here first.
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
#5 Updated by Alex Elder about 11 years ago
OK, I'm going to interpret this as:
Any write operation on a layered image will be preceded
by an existence check of the object to be written before
proceeding with the write.
It won't include fetching the data from the parent object,
which will be covered by 2855.
#10 Updated by Alex Elder about 11 years ago
- Estimated time set to 0.00 h
This work actually did begin last week, after getting STAT
calls implemented (see http://tracker.ceph.com/issues/4007).
But it is preliminary and I'll need to port whatever was done
to the latest code, so for now I'm going to keep it marked