Project

General

Profile

Bug #9039

Using COPY on radosgw to copy object from one bucket to another that's in another pool should either copy data or be rejected

Added by Sylvain Munaut over 9 years ago. Updated over 9 years ago.

Status:
Resolved
Priority:
High
Assignee:
Target version:
-
% Done:

0%

Source:
Development
Tags:
Backport:
firefly
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

Currently if you copy an object from a bucket to another one which is in another rados pool, things will just break. Copy is accepted but you can't re-read the object.

Either the data should be copied. Or the operation should be refused at the very least.

Associated revisions

Revision 5d3a7e59 (diff)
Added by Yehuda Sadeh over 9 years ago

rgw: copy object data if target bucket is in a different pool

Fixes: #9039
Backport: firefly

The new manifest does not provide a way to put the head and the tail in
separate pools. In any case, if an object is copied between buckets in
different pools, we may really just want the object to be copied, rather
than reference counted.

Signed-off-by: Yehuda Sadeh <>

Revision 459dca16 (diff)
Added by Yehuda Sadeh over 9 years ago

rgw: copy object data if target bucket is in a different pool

Fixes: #9039
Backport: firefly

The new manifest does not provide a way to put the head and the tail in
separate pools. In any case, if an object is copied between buckets in
different pools, we may really just want the object to be copied, rather
than reference counted.

Signed-off-by: Yehuda Sadeh <>
(cherry picked from commit 5d3a7e595f47455896304bf358e5251915d0f16f)

History

#1 Updated by Ian Colle over 9 years ago

  • Assignee set to Yehuda Sadeh

#2 Updated by Yehuda Sadeh over 9 years ago

  • Priority changed from Normal to High

#3 Updated by Yehuda Sadeh over 9 years ago

That sounds like an issue with the new (firefly) manifest.

#4 Updated by Sylvain Munaut over 9 years ago

Really ? I didn't see anything in the code that checked whether the destination bucket was in the same pool or not and would even try to do the right thing, but maybe I missed it.

#5 Updated by Yehuda Sadeh over 9 years ago

The problem is that it is implicitly assumed with the new manifest that the tail is going to reside at the same pool where the head is. This is an oversight and should be fixed. I think that a first go at this will be to do a data copy as you suggested. We can later improve the manifest.

#6 Updated by Sylvain Munaut over 9 years ago

Well, I think data copy is the right thing to do. If I put bucket in different pool is because they're configured differently (like more replication or using erasure or slower storage) and when copying a file to a bucket with this other pool, I excpect to get the specs of whatever spec I'm copying TO and the one I'm copying FROM.

#7 Updated by Sage Weil over 9 years ago

  • Status changed from New to Pending Backport
  • Source changed from other to Development
  • Backport set to firefly

the restriping fix patches also need to go to dumpling...

#8 Updated by Yehuda Sadeh over 9 years ago

The restriping tool never made it to dumpling. It actually isn't even in firefly.

#9 Updated by Sage Weil over 9 years ago

  • Status changed from Pending Backport to 12

not sure what the state of this bug is then.. yehuda?

#10 Updated by Yehuda Sadeh over 9 years ago

sent a pull request now, #2632

#11 Updated by Yehuda Sadeh over 9 years ago

  • Status changed from 12 to Pending Backport

#12 Updated by Yehuda Sadeh over 9 years ago

  • Status changed from Pending Backport to Resolved

Also available in: Atom PDF