Feature #66164
opentool to clean up orphaned bucket index entries
0%
Description
We came across an issue where an Object won't get deleted.
Our users made us aware of an object that can get listed, but not downloaded or info pulled through S3 and also won't delete.
Every deletion will be responded with an 204 but the OMAP entry on the Bucket index object will not be cleaned up so the object stays listable.
Steps to reproduce:> create object using S3> delete the rados object associated to the S3 object
-> try and delete the Object using S3
My best guess as to how this orphan happend is some kind of hiccup or race condition which I can't debug anymore since it happend a while ago.
I would expect a subsequent delete request to at least clean up the OMAP entry even if the rados object is gone.
Updated by Casey Bodley 17 days ago
i don't think there's any tooling to repair this. we might consider adding an extra option to radosgw-admin object rm so it would delete from the index even if the head object is gone, but implementing that is not trivial
Updated by Johannes Liebl 16 days ago
Having a force or similar option in radosgw-admin would be helpful. The main thing that is bothering me is that such "Failed" delete operations get responded with 204 which seems wrong if nothing happens. In my opinion it would be the easiest to just delete the index even if the backing object is gone upon a delete request since a User wants the object gone anyways.
Updated by Casey Bodley 3 days ago
- Tracker changed from Bug to Feature
- Subject changed from RGW orphan omap entry won't get cleaned up to tool to clean up orphaned bucket index entries
- Tags set to low-hanging-fruit
- Regression deleted (
No) - Severity deleted (
2 - major)
Updated by Casey Bodley 3 days ago
- Related to Bug #63935: Bucket index for object remaining after a DELETE added