]> git.apps.os.sepia.ceph.com Git - ceph.git/commit
rgw: fix BZ 1500904, Stale bucket index entry remains after object deletion 18794/head
authorJ. Eric Ivancich <ivancich@redhat.com>
Fri, 3 Nov 2017 13:15:13 +0000 (09:15 -0400)
committerAbhishek Lekshmanan <abhishek@suse.com>
Tue, 7 Nov 2017 17:27:59 +0000 (18:27 +0100)
commit36e214c67b6982cc7a85e08dedc83ea61e56d6a4
treee9fa91d3f3bcf2df7bbb6a986ffde51c87c8c2f8
parent6bc121ddeec4b12c91ae5ac982ad113bda14d2bf
rgw: fix BZ 1500904, Stale bucket index entry remains after object deletion

We have a race condition:

 1. RGW client #1: requests an object be deleted.
 2. RGW client #1: sends a prepare op to bucket index OSD #1.
 3. OSD #1:        prepares the op, adding pending ops to the bucket dir entry
 4. RGW client #2: sends a list bucket to OSD #1
 5. RGW client #2: sees that there are pending operations on bucket
                   dir entry, and calls check_disk_state
 6. RGW client #2: check_disk_state sees that the object still exists, so it
                   sends CEPH_RGW_UPDATE to bucket index OSD (#1)
 7. RGW client #1: sends a delete object to object OSD (#2)
 8. OSD #2:        deletes the object
 9. RGW client #2: sends a complete op to bucket index OSD (#1)
10. OSD #1:        completes the op
11. OSD #1:        receives the CEPH_RGW_UPDATE and updates the bucket index
                   entry, thereby **RECREATING** it

Solution implemented:

At step #5 the object's dir entry exists. If we get to beginning of
step #11 and the object's dir entry no longer exists, we know that the
dir entry was just actively being modified, and ignore the
CEPH_RGW_UPDATE operation, thereby NOT recreating it.

Signed-off-by: J. Eric Ivancich <ivancich@redhat.com>
(cherry picked from commit b33f529e79b74314a2030231e1308ee225717743)
src/cls/rgw/cls_rgw.cc
src/rgw/rgw_rados.cc