Project

General

Profile

Subtask #2854

Feature #2851: krbd: RBD layering support

krbd: write path

Added by Anonymous over 11 years ago. Updated about 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
-
% Done:

100%

Source:
Tags:
Backport:
Reviewed:
Affected Versions:
Pull request ID:

Description

verify the target object exists in write requests. if we fail with ENOENT, trigger a copy-up.


Subtasks

Subtask #4007: libceph: support STAT osd operationResolvedAlex Elder

History

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

#3 Updated by Greg Farnum about 11 years ago

Pretty sure this is about the rbd locking and fencing.

#4 Updated by Sage Weil about 11 years ago

  • Subject changed from krbd: guard writes to krbd: write path
  • Description updated (diff)

rbd write path.. 'guard' in the sense that the write has a check to verify the object already exists.

#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.

#6 Updated by Alex Elder about 11 years ago

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

#7 Updated by Ian Colle about 11 years ago

  • Tracker changed from Tasks to Feature

#8 Updated by Alex Elder about 11 years ago

  • Target version set to v0.58

#9 Updated by Alex Elder about 11 years ago

  • Target version set to v0.58
  • Estimated time set to 0.00 h

#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
as "new."

#11 Updated by Ian Colle about 11 years ago

  • Status changed from New to Closed

Tracking under 3418

Also available in: Atom PDF