librbd: generalized deep copy function #16238

trociny · 2017-07-10T10:49:00Z

(mostly taken from rbd-mirror image sync)

Signed-off-by: Mykola Golub mgolub@mirantis.com

trociny · 2017-07-10T10:51:36Z

@dillaman I created this PR at this stage just to make discussion easier.

The current version still needs cleanup and unit tests, and works only if source and destination image object sizes are the same. Now I am trying to generalize it to work when src and dst object sizes differ.

The approach I am trying is to substitute one to one src to dst object mapping to src object extent to dst object extent mapping, and modify ObjectCopyRequest to be actually ObjectExtentCopyRequest, which is called to copy an src object N extent [a, b] to dst object M extent [c, d].

Is this approach that you were thinking about?

It looks like the most complicated part here is to modify ObjectCopyRequest::compute_diffs. I think TRUNC and REMOVE operations that made sense for object to object mapping should be replaced by
DISCARD (ZERO) op now. Then it might lead to empty or not tuncated objects at the destination?

Also, not sure what to do with m_snap_object_states and update_object_map...

trociny · 2017-07-11T14:30:15Z

@dillaman I see now that my "copy extent by extent approach" is actually wrong (due to the problems I described above). It looks like what I need is:

for every dst object

map it to the list of src objects (extents)
copy snapshots from these src objects to dst object (and build snap_map)
copy object extents for every snapshot
update dst object state in object map

(actually not this looks to me like what you initially suggested)

amitkumar50 · 2017-08-16T12:29:27Z

src/librbd/image/CopyRequest.cc

+    return;
+  }
+
+  // rollback the object map (copy snapshot object map to HEAD)


@trociny How good It would be start comment from capital letter?
// Rollback the object map (copy snapshot object map to HEAD)

amitkumar50 · 2017-08-16T12:31:17Z

src/librbd/image_copy/SnapshotCreateRequest.cc

+
+  ldout(m_cct, 20) << dendl;
+
+  // Change the image size on disk so that the snapshot picks up


@trociny I believe multi-line comment should be inside /* */

amitkumar50 · 2017-08-16T12:31:50Z

src/librbd/image_copy/SnapshotCreateRequest.cc

+  }
+
+  {
+    // adjust in-memory image size now that it's updated on disk


@trociny I believe It would be even better if we start comment with capital letter something as:
// Adjust in-memory image size now that it's updated on disk

amitkumar50 · 2017-08-16T12:32:14Z

src/librbd/image_copy/SnapshotCreateRequest.cc

+  ldout(m_cct, 20) << "object_map_oid=" << object_map_oid << ", "
+                   << "object_count=" << object_count << dendl;
+
+  // initialize an empty object map of the correct size (object sync


@trociny multiline comment inside /* */

trociny · 2017-08-28T08:19:38Z

@dillaman Here is updated copy_deep implementation, which supports different source and destination image object sizes. It still needs unit tests though.

Could you please look at the current version, so I could be sure I go in the right direction?

Also, I would like to discuss the scope of this PR. I have added copy_deep internal function, which is currently used only in tests. I plan to use this function in rbd-mirror instead of image_sync. Also, I
think image_copy::ObjectCopyRequest should be integrated (somehow) into io::ObjectRequest to be called for live migrating images. Is this what you was thinking initially? Would just copy_deep internal
function implementation (as it currently is) be enough for this PR?

trociny · 2017-08-29T17:38:15Z

@dillaman I have (temporary) added a commit that makes rbd-mirror to use generalized copy deep. I think it can be pushed as a separated PR later. It is here just to show how I plan to use copy deep.

dillaman · 2017-08-30T01:01:32Z

src/librbd/CMakeLists.txt

@@ -34,13 +34,18 @@ set(librbd_internal_srcs
  exclusive_lock/StandardPolicy.cc
  image/CloneRequest.cc
  image/CloseRequest.cc
+  image/CopyRequest.cc


Nit: I would probably move this up to the root and rename to DeepCopyRequest

dillaman · 2017-08-30T01:01:52Z

src/librbd/CMakeLists.txt

  image/CreateRequest.cc
  image/OpenRequest.cc
  image/RefreshParentRequest.cc
  image/RefreshRequest.cc
  image/RemoveRequest.cc
  image/SetFlagsRequest.cc
  image/SetSnapRequest.cc
+  image_copy/ImageCopyRequest.cc


Nit: subdirectory should be deep_copy

dillaman · 2017-08-30T01:11:52Z

src/librbd/image_copy/ImageCopyRequest.cc

+    }
+  }
+
+  // Recalculate for destination


Why would the destination size be different on a copy?

Not the destination image size but total number of objects (m_end_object_no) may be different if src and dst object sizes are different.

Good point, but the way that ObjectCopyRequest is currently designed, it assumes that the source and destination have matching layouts (order and striping v2). If we want to support overriding those settings on the destination, which I think is important, that class needs to be redesigned so that you loop over all destination objects and then the ObjectCopyRequest state machine loads diffs for all source objects that overlap w/ the destination object's layout, computes the necessary ops over the overlap, and does the single destination write per snapshot.

Given that, I think you would drop this logic and change the loop above to iterate over the destination image instead of the source image.

I suppose it is exactly how it works now? I.e. here we calculate number of destination objects and then for every destination object call ObjectCopyRequest. In my modified implementation it expects destination object number as a param, and then it maps dst object to src objects, loads diffs, etc...

But I forgot about striping v2 feature. I need to refresh memory about how it works, but right now I think the code will not work correctly in general case if striping is enabled.

I missed that you adjusted it to handle that case. All object and offset calculation should use the Striper logic instead of attempting to re-implement it all over the place. You would use the striper to calculate the image extents covered by the destination object and then for each image extent you would map that back to source object extents.

dillaman · 2017-08-30T01:13:16Z

src/librbd/image_copy/ImageCopyRequest.cc

+#include "ObjectCopyRequest.h"
+#include "common/errno.h"
+#include "librbd/Utils.h"
+#include "tools/rbd_mirror/ProgressContext.h"


dillaman · 2017-08-30T01:13:28Z

src/librbd/image_copy/SnapshotCreateRequest.cc

+#include "osdc/Striper.h"
+
+#define dout_context g_ceph_context
+#define dout_subsys ceph_subsys_rbd_mirror


Nit: adjust

dillaman · 2017-08-30T01:27:22Z

src/tools/rbd_mirror/ImageSync.cc

 }

 template <typename I>
-void ImageSync<I>::handle_refresh_object_map(int r) {
-  dout(20) << dendl;
+void ImageSync<I>::handle_unset_sync_point_snap_contex(int r) {


dillaman · 2017-08-30T01:27:34Z

src/tools/rbd_mirror/ImageSync.h

   *    |
   *    v
   * COPY_IMAGE . . . . . . . . . . . . . .
   *    |                                 .
   *    v                                 .
-   * COPY_OBJECT_MAP (skip if object      .
-   *    |             map disabled)       .
+   * UNSET_SYNC_POINT_SNAP_CONTEX         .


dillaman · 2017-08-30T01:27:37Z

src/tools/rbd_mirror/ImageSync.h

@@ -79,18 +76,15 @@ class ImageSync : public BaseRequest {
   * CREATE_SYNC_POINT (skip if already exists and
   *    |               not disconnected)
   *    v
-   * COPY_SNAPSHOTS
+   * SET_SYNC_POINT_SNAP_CONTEX


dillaman · 2017-08-30T01:31:09Z

src/test/rbd_mirror/test_mock_ImageSync.cc

-      .WillOnce(Invoke([this, &mock_snapshot_copy_request, r]() {
-          m_threads->work_queue->queue(mock_snapshot_copy_request.on_finish, r);
-        }));
+  void expect_set_sync_point_snap_contex(


dillaman · 2017-08-30T01:31:15Z

src/test/rbd_mirror/test_mock_ImageSync.cc

-      .WillOnce(Invoke([this](Context *ctx) {
-          m_threads->work_queue->queue(ctx, 0);
-        }));
+  void expect_unset_sync_point_snap_contex(


dillaman · 2017-08-30T01:32:17Z

@trociny Looks really good to me -- just nits basically. Might be even clearer history-wise if you just git mv the support classes over to librbd along w/ the associated unit tests

trociny · 2017-08-30T07:37:39Z

src/librbd/image_copy/ObjectCopyRequest.cc

+      }
+
+      // prepare the object map state
+      // XXXMG: how to support OBJECT_EXISTS_CLEAN?


@dillaman What do you think about this? The commented code is from the original image_sync. Now, thinking about this more it looks to me I can safely use the same, i.e. just uncomment this code and remove m_snap_object_states[end_dst_snap_id] = OBJECT_EXISTS.

Seems OK to me

trociny · 2017-09-05T14:19:57Z

@dillaman updated according to your comments + unit tests added.

Though right now I think I unnecessarily limited DeepCopyRequest interface. It expects src_image_ctx to be set to snap, that is used as snap_id_end, and for snap_id_start we always use 0.

I am planning to generalize DeepCopyRequest to expect copy_point_start and copy_point_end arguments provided.

trociny · 2017-09-11T11:00:52Z

@dillaman updated. The commit that makes rbd-mirror to use generalized copy deep is still here to show how deep copy is used. I can push it as a separated PR if it makes reviewing and merging easier.

dillaman · 2017-09-13T15:20:50Z

src/librbd/DeepCopyRequest.cc

+    return -EINVAL;
+  }
+
+  if (m_src_image_ctx->snap_info.find(m_snap_id_end) ==


For the rbd CLI's deep-copy, it might be nice to support copying to the HEAD revision if desired (i.e. if the image is not being actively modified, no need to create a snapshot).

dillaman · 2017-09-13T15:21:29Z

src/librbd/DeepCopyRequest.cc

+}
+
+template <typename I>
+void DeepCopyRequest<I>::send_remove_copy_snapshot() {


Since this state machine didn't create the snapshot, perhaps it shouldn't be responsible for deleting it -- especially if the goal is to have rbd-mirror use its own snapshot namespace eventually.

dillaman · 2017-09-13T15:29:47Z

src/librbd/DeepCopyRequest.cc

+void DeepCopyRequest<I>::send_copy_object_map() {
+  m_dst_image_ctx->owner_lock.get_read();
+  m_dst_image_ctx->snap_lock.get_read();
+  if (!m_dst_image_ctx->test_features(RBD_FEATURE_OBJECT_MAP,


... also skip if copying from the HEAD revision since the object copy should have updated the HEAD object map

dillaman · 2017-09-13T16:57:42Z

src/librbd/DeepCopyRequest.cc

+#include "librbd/deep_copy/SnapshotCopyRequest.h"
+#include "librbd/operation/SnapshotRemoveRequest.h"
+
+#define dout_context g_ceph_context


dillaman · 2017-09-13T16:57:47Z

src/librbd/deep_copy/ImageCopyRequest.cc

+#include "librbd/Utils.h"
+#include "osdc/Striper.h"
+
+#define dout_context g_ceph_context


dillaman · 2017-09-13T17:45:22Z

src/librbd/deep_copy/ObjectCopyRequest.cc

+  m_snap_object_sizes = {};
+  m_src_object_offsets = {};
+
+  std::vector<std::pair<uint64_t, uint64_t>> file_extents;


Nit: file -> image

dillaman · 2017-09-13T17:49:33Z

src/librbd/deep_copy/ObjectCopyRequest.cc

+
+template <typename I>
+void ObjectCopyRequest<I>::send_list_snaps() {
+  // starting copy from highest src object number is important for truncate


This needs to be able to handle a truncate of any source object -- and w/ striping, it's possible that the "end" image extent of the destination object is not align with the highest source object number.

If a destination object number x is mapped to src object numbers a, b, c (due to different object sizes) I assume that it will be always a < b < c for any striping. Now, if reading src objects I see that c does not exist, and b is truncated, I can truncate the destination object up to b truncated length. If b is truncated but c exists I know that I need to write a hole.

For this reason I start listing src objects from the highest one.

If fancy striping is used, I am not sure that logic is correct:

src:

object size 2

stripe unit = 1

stripe count = 3

dst:

object size 4

no fancy striping

The mapping would be: object 1@0~1, object 2@0~1, object 3@0~1, object 1@1~1. If object 3 doesn't exist in this case, that's a hole and not a truncate.

@dillaman It is good to know. Thanks!

dillaman · 2017-09-13T17:57:48Z

src/librbd/deep_copy/ObjectCopyRequest.h

+    bufferlist out_bl;
+  };
+
+  typedef std::map<uint64_t, std::vector<std::pair<uint64_t, size_t>>> ObjectOffsets; // src_object_id -> list of (object_off, len)


Nit: ObjectExtents is the terminology used elsewhere

dillaman · 2017-09-13T18:00:59Z

src/librbd/deep_copy/ObjectCopyRequest.cc

+    auto len = it.second;
+
+    interval_set<uint64_t> copy_interval;
+    copy_interval.insert(src_object_off, src_object_off + len);


Normal interval_set insert logic is value and length not start and end values.

Thinking about the complexity of this some more, I wonder if it would make more sense to refactor the CopyOp computation logic and separate out the read and write ops into two different collections. The reads would be ordered by write/read snapshots and source object and the writes could be ordered by write snapshot.

We would change the flow a little so that for each source object, we first list its diff then perform the read. This allows us to avoid repeating all source object reads should a retry be required. Once all the reads have been performed across all source objects, we can perform the write stage.

When computing the diffs, instead of creating remove/zero/truncate ops, we could instead just track an interval set of zeroed locations for the destination object at the current write snapshot. Then as part of the write step, we would generate zero, truncate or remove ops I think pretty easily.

dillaman · 2017-09-13T19:11:59Z

src/librbd/deep_copy/ObjectCopyRequest.h

+  void send_update_object_map();
+  void handle_update_object_map(int r);
+
+  Context *start_dst_op(RWLock &owner_lock);


Nit: start_lock_op or start_destination_op

trociny · 2017-10-09T14:19:04Z

@dillaman updated. Still open questions:

Is the recently added MetadataCopyRequest should to be a part of deep_copy or rather a separate request?
I don't know how to set OBJECT_EXISTS_CLEAN flag properly (probably because I am not sure I understand this feature).

dillaman · 2017-10-11T00:58:07Z

@trociny The MetadataCopyRequest just needs to run once somewhere when doing a deep-copy. I added it to rbd::mirror::ImageSync as the last state since it would only need to execute once in theory (i.e. in case the image copy was canceled). The CLEAN flag should be set when the previous snapshot's object map was OBJECT_EXISTS or OBJECT_EXISTS_CLEAN and there are no diffs in the current snapshot (HEAD) revision.

trociny · 2017-10-11T10:26:10Z

@dillaman updated to deal with OBJECT_EXISTS_CLEAN.

As for MetadataCopyReques, if I understand correctly your idea, I will leave it as is so far, so DeepCopyRequest will not call it. And later, when I need it for migration project (so metadata would be copied on migration too), I can move it to somewhere to librbd (where it could be BTW?).

dillaman · 2017-10-11T12:01:12Z

@trociny Sorry -- I was saying that I think the metadata copy should be moved to deep-copy as well. I was just trying to say that you could move it anywhere so long as it executes at the end of the deep-copy.

trociny · 2017-10-11T12:10:35Z

@dillaman Thanks. I will move MetadataCopyReques. Also, my "OBJECT_EXISTS_CLEAN" code still needs some work.

trociny · 2017-10-12T18:32:03Z

@dillaman updated

trociny · 2017-10-30T21:05:51Z

@dillaman I have updated fsx to support deep-copy. I have not tested it well yet, and I still need to enable it in qa. Right now I have a question though. I had to link fsx with internal libraries. Might we want to add deep_copy to API instead?

dillaman · 2017-10-31T01:01:16Z

@trociny Yeah -- add it to the API since I can see this being added to the rbd CLI as well in a future PR.

ceph-jenkins · 2017-11-01T12:21:37Z

submodules for project are unmodified

ceph-jenkins · 2017-11-01T12:22:50Z

all commits in this PR are signed

ceph-jenkins · 2017-11-01T12:26:10Z

OK - docs built

trociny · 2017-11-01T12:41:37Z

@dillaman I have added deep_copy to API and enabled fsx qa tests. And observing fsx test failures on teuthology now [1], which I still need to track down (failed to reproduce locally so far, the failed fsx command successfully completes on my "vstart" env).

Meantime I have questions about deep_copy API:

In the current version it is possible to set only end snap (by setting src image snap context). May be we want to allow to set start snap too (start_snap_name, end_snap_name params)? It could be used for incremental backup.
As it is seen in the fsx case, copying end_snap ("copy" snapshot) to destination is not useful in all cases and will require additional work from the user if she wants a "clone" like behavior. May be we need to improve this?

[1] http://pulpito.ceph.com/trociny-2017-11-01_10:45:27-rbd-wip-mgolub-testing-distro-basic-smithi/

ceph-jenkins · 2017-11-01T12:56:31Z

make check succeeded

ceph-jenkins · 2017-11-01T13:07:56Z

make check succeeded

dillaman · 2017-11-02T01:42:50Z

src/include/rbd/librbd.h

+CEPH_RBD_API int rbd_deep_copy(rbd_image_t src, rados_ioctx_t dest_io_ctx,
+			       const char *destname, rbd_image_options_t dest_opts);
+CEPH_RBD_API int rbd_deep_copy_with_progress(rbd_image_t image,
+                                             rados_ioctx_t dest_p,


Nit: dest_io_ctx?

trociny · 2017-11-03T11:30:12Z

src/librbd/deep_copy/ObjectCopyRequest.cc

+    for (auto &p : src_object_extents) {
+      for (auto &s : p.second) {
+        m_src_objects.insert(s.objectno);
+        m_src_object_extents.push_back({s.objectno, s.offset, s.length});


@dillaman I think I have found an issue here.
I need m_src_object_extents list to be ordered by a destination object offset (so I could sequentially write extents to the destination object; alternatively I would need to track src_offset->dst_offset). But I did not realize Striper::file_to_extents returned a map ordered by object and the order is lost. So I need to sort extents returned in src_object_extents.

Right now I don't see a good way. It looks like using Striper::extent_to_file + Striper::file_to_extents like above I can't map dst_object_offset -> src_object, src_object_offset.

Ah, it looks like I just need to use a different version of Striper::file_to_extents.

No, the version that returns a list, uses assimilate_extents which does the same that my code above, so it returns the list in wrong order (

It looks I would need to extend Striper to provide file_to_extents version I need?

@dillaman I fixed this by introducing src_to_dst_object_offset() (see the fixup commit 48029c2). Do you think it could be a solution or do we need something more efficient (e.g. update Striper to return results we need)?

After this change fsx still fails but in different place. Need to track this further.

@dillaman Another problem with compute_src_object_extents() found: I need to split src object extents, if the destination stripe_unit is smaller than the source stripe_unit. The fixup commit 9024db9 contains the fix for this issue too. Now it is much better: I have not been able to make fsx fail so far!

I will squash the fixup after your review.

trociny · 2017-11-04T10:23:16Z

teuthology fsx tests pass now: http://pulpito.ceph.com/trociny-2017-11-04_09:03:20-rbd-wip-mgolub-testing-distro-basic-ovh/

dillaman · 2017-11-04T14:52:29Z

src/librbd/deep_copy/ObjectCopyRequest.cc

+          assert(s.length >= stripe_unit);
+          auto dst_object_offset = src_to_dst_object_offset(s.objectno, s.offset);
+          m_src_object_extents[dst_object_offset] = {s.objectno, s.offset,
+                                                     stripe_unit};


What would happen if the dst_object_offset is in the middle of a dest stripe? For example, if the source extent was 2~2 (stripe of 2) and the destination extext was 0~3 (stripe of 3), the first byte of the source extent would map to the destination extent 2~1 but the last byte of the min stripe would go somewhere else.

@dillaman I am not sure I see exactly what you mean, but taking the condition that is used for stripe_unit on image creation:

(1 << order) % stripe_unit == 0 && stripe_unit <= (1 << order)

which I think can be rewritten as:

stripe_unit == (1 << x), where x <= order

which means that a situation like you described is not possible?

OK -- fair enough if odd stripe units are prevented. We have plenty of "fsx" testing time to catch any potential regressions. Go ahead and squash the fixup commit (or just prefix it w/ "librbd") for merging.

@dillaman thanks. Rebased.

dillaman · 2017-11-05T18:21:07Z

src/test/librbd/test_mock_DeepCopyRequest.cc

+} // namespace librbd
+
+// template definitions
+template class librbd::DeepCopyRequest<librbd::MockTestImageCtx>;


Nit: no need to explicitly instantiate -- it's causing a compile warning:

In file included from /home/jdillaman/ceph/src/test/librbd/test_mock_DeepCopyRequest.cc:148:0:
/home/jdillaman/ceph/src/librbd/DeepCopyRequest.cc:64:6: warning: ‘void librbd::DeepCopyRequest::cancel() [with ImageCtxT = librbd::{anonymous}::MockTestImageCtx]’ defined but not used [-Wunused-function]
void DeepCopyRequest::cancel() {
^~~~~~~~~~~~~~~~~~

@dillaman fixed. Thanks.

Signed-off-by: Mykola Golub <mgolub@mirantis.com>

(so it could be used for logging image options) Signed-off-by: Mykola Golub <to.my.trociny@gmail.com>

(based on rbd-mirror image sync) Signed-off-by: Mykola Golub <mgolub@mirantis.com>

Signed-off-by: Mykola Golub <mgolub@mirantis.com>

Signed-off-by: Mykola Golub <to.my.trociny@gmail.com>

dillaman

lgtm

trociny added feature rbd labels Jul 10, 2017

trociny requested a review from dillaman July 10, 2017 10:49

amitkumar50 suggested changes Aug 16, 2017

View reviewed changes

trociny force-pushed the wip-copy-deep branch from 8848246 to e595c5b Compare August 28, 2017 07:46

dillaman reviewed Aug 30, 2017

View reviewed changes

trociny commented Aug 30, 2017

View reviewed changes

trociny force-pushed the wip-copy-deep branch from ec00195 to eb8bd12 Compare September 5, 2017 14:12

trociny force-pushed the wip-copy-deep branch from eb8bd12 to 5709ae6 Compare September 11, 2017 10:55

trociny changed the title ~~[DNM] librbd: generalized copy deep function~~ librbd: generalized copy deep function Sep 11, 2017

trociny changed the title ~~librbd: generalized copy deep function~~ librbd: generalized deep copy function Sep 11, 2017

dillaman reviewed Sep 13, 2017

View reviewed changes

trociny force-pushed the wip-copy-deep branch from 5709ae6 to 32ad788 Compare October 9, 2017 14:12

trociny force-pushed the wip-copy-deep branch from 32ad788 to 89294dd Compare October 11, 2017 10:18

trociny force-pushed the wip-copy-deep branch from 89294dd to e47f813 Compare October 12, 2017 17:29

trociny force-pushed the wip-copy-deep branch from e47f813 to d62473f Compare October 14, 2017 16:16

ceph deleted a comment from trociny Oct 16, 2017

trociny force-pushed the wip-copy-deep branch from b40ad47 to 1a98ef3 Compare November 1, 2017 12:21

dillaman reviewed Nov 2, 2017

View reviewed changes

dillaman added the wip-jason-testing label Nov 2, 2017

trociny force-pushed the wip-copy-deep branch from 1a98ef3 to 8750cf4 Compare November 2, 2017 08:00

trociny commented Nov 3, 2017

View reviewed changes

trociny force-pushed the wip-copy-deep branch 2 times, most recently from f1ff5fe to 9024db9 Compare November 3, 2017 21:28

dillaman reviewed Nov 4, 2017

View reviewed changes

trociny force-pushed the wip-copy-deep branch from 9024db9 to ebdeaa0 Compare November 4, 2017 17:48

dillaman reviewed Nov 5, 2017

View reviewed changes

Mykola Golub and others added 7 commits November 6, 2017 10:26

test/librbd: set rand seed for all tests

ca25c56

Signed-off-by: Mykola Golub <mgolub@mirantis.com>

librbd: export ImageOptions print operator

a84b0a4

(so it could be used for logging image options) Signed-off-by: Mykola Golub <to.my.trociny@gmail.com>

librbd: generalized deep copy function

5a1a217

(based on rbd-mirror image sync) Signed-off-by: Mykola Golub <mgolub@mirantis.com>

rbd-mirror: use generalized deep copy for image sync

73f50a1

Signed-off-by: Mykola Golub <mgolub@mirantis.com>

librbd: add deep_copy function to API

97db2b2

Signed-off-by: Mykola Golub <to.my.trociny@gmail.com>

test/librbd: tweak fsx to optionally use deep-copy instead of clone

428461a

Signed-off-by: Mykola Golub <to.my.trociny@gmail.com>

qa/suites/rbd: enable fsx deep_copy test case

3a09801

Signed-off-by: Mykola Golub <to.my.trociny@gmail.com>

trociny force-pushed the wip-copy-deep branch from ebdeaa0 to 3a09801 Compare November 6, 2017 09:33

dillaman approved these changes Nov 6, 2017

View reviewed changes

dillaman merged commit baa65c2 into ceph:master Nov 6, 2017

trociny deleted the wip-copy-deep branch November 6, 2017 17:23


		ldout(m_cct, 20) << dendl;

		// Change the image size on disk so that the snapshot picks up

librbd: generalized deep copy function #16238

librbd: generalized deep copy function #16238

Conversation

trociny commented Jul 10, 2017

trociny commented Jul 10, 2017

trociny commented Jul 11, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

trociny commented Aug 28, 2017

trociny commented Aug 29, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dillaman commented Aug 30, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

trociny commented Sep 5, 2017

trociny commented Sep 11, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dillaman Sep 14, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

trociny commented Oct 9, 2017

dillaman commented Oct 11, 2017

trociny commented Oct 11, 2017

dillaman commented Oct 11, 2017

trociny commented Oct 11, 2017

trociny commented Oct 12, 2017

trociny commented Oct 30, 2017

dillaman commented Oct 31, 2017

ceph-jenkins commented Nov 1, 2017

ceph-jenkins commented Nov 1, 2017

ceph-jenkins commented Nov 1, 2017

trociny commented Nov 1, 2017

ceph-jenkins commented Nov 1, 2017

ceph-jenkins commented Nov 1, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

trociny Nov 3, 2017 • edited

Choose a reason for hiding this comment

trociny commented Nov 4, 2017

dillaman Nov 4, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dillaman left a comment

Choose a reason for hiding this comment

trociny commented Jul 11, 2017 •

edited

dillaman commented Aug 30, 2017 •

edited

dillaman Sep 14, 2017 •

edited

trociny Nov 3, 2017 •

edited

dillaman Nov 4, 2017 •

edited