]> git.apps.os.sepia.ceph.com Git - ceph.git/commit
rgw: fix BZ 1500904, Stale bucket index entry remains after object deletion 20293/head
authorJ. Eric Ivancich <ivancich@redhat.com>
Fri, 3 Nov 2017 13:15:13 +0000 (09:15 -0400)
committerNathan Cutler <ncutler@suse.com>
Sun, 4 Feb 2018 04:10:42 +0000 (05:10 +0100)
commit1b075dd44030f17f95dfc1ade6259f049cc7bdc7
tree400ae7fcb603fa85369b52d21fbcf1bb9405ae68
parent2c5186c77b1fac49a1cfa6bdc706596820b176c3
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)

Conflicts: (backported substantial changes only; omitted cleanups)
        src/cls/rgw/cls_rgw.cc
src/rgw/rgw_rados.cc
src/cls/rgw/cls_rgw.cc