Hi Corey, I updated the regression potential section, and this patch is for bionic luminous.
Thanks, Dongdong ** Description changed: [Impact] This bug will cause the bucket not able to abort the multipart upload and leaving the stale multiple entries behind for those buckets which had partial multipart uploads before the resharding. [Test Case] Deploy a latest luminous(12.2.13) ceph cluter Create a bucket upload a big file (200M+) to that bucket Press "Ctrl + C" after several part (each part is 15M) had been uploaded Manually reshard the bucket to 4 shards Abort the multipart uploading Without the fix, you will not able to abort the previous uploading [Regression Potential] - Low - this fix has been accept upstream in later releases since from Mimic. + Low - this fix has been accept upstream in later releases since from Mimic, but it there is a super large multipart uploads, all the multi-entry will now be correctly mapped to the expected shard, which will cause this shard contain more omap entries than before, which might some slow when listing the shard [Original Bug Report] There is a bug during the resharding for those multipart entries. For all the multipart entries, the hash source should be the object name so that all those entries can still be distributed to one same bucket index shard object. Right now the code just calculate the shard id based on each entry's name, which is wrong This can cause the bucket not able to abort the multipart upload and leave the stale multiple entries behind. https://tracker.ceph.com/issues/43583 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1868364 Title: rgw: unable to abort multipart upload after the bucket got resharded To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1868364/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
