]> git-server-git.apps.pok.os.sepia.ceph.com Git - ceph.git/commit
rgw: fix BZ 1500904, Stale bucket index entry remains after object deletion 18709/head
authorJ. Eric Ivancich <ivancich@redhat.com>
Fri, 3 Nov 2017 13:15:13 +0000 (09:15 -0400)
committerJ. Eric Ivancich <ivancich@redhat.com>
Fri, 3 Nov 2017 16:58:05 +0000 (12:58 -0400)
commitb33f529e79b74314a2030231e1308ee225717743
tree7d870c1b7d26c511bd9eb969a68b6a9ddb826be9
parenta27b28e507fd81321966f993ad9427a8bfaf5ddf
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>
src/cls/rgw/cls_rgw.cc
src/rgw/rgw_rados.cc