Bug #9039
closed
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 almost 10 years ago.
Updated over 9 years ago.
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.
- Assignee set to Yehuda Sadeh
- Priority changed from Normal to High
That sounds like an issue with the new (firefly) manifest.
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.
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.
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.
- 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...
The restriping tool never made it to dumpling. It actually isn't even in firefly.
- Status changed from Pending Backport to 12
not sure what the state of this bug is then.. yehuda?
sent a pull request now, #2632
- Status changed from 12 to Pending Backport
- Status changed from Pending Backport to Resolved
Also available in: Atom
PDF