Ceph » rbd

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.

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
support this.

Pretty sure this is about the rbd locking and fencing.

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.

Work on this won't really begin until the read path work
has completed (http://tracker.newdream.net/issues/2853).