[..] Yehuda Sadeh-Weinraub writes: > > Yes, that would be a normal behaviour. The primary should not have > concurrent sync operations on the same object if object has not > completed previous sync operations. Looking at the log it really seems > that we don't identify the concurrent sync operation on the same > object. This should have been fixed by commit > edea6d58dd25995bcc1ed4fc5be6f72ce4a6835a. Can you try to verify what > went wrong there (whether can_do_op() returned true and why)? Looked into this a bit, can_do_op() has returned true for the case when primary issues a Fetch (or GET) and when a delete is issued,(even though the Fetch is still not complete yet) by putting a debug log around when we clear the keys, both the delete op and the get op creates and deletes the same key successfully. Which makes me suspect, that different instances of RGWBucketIncSyncShardMarkerTrack are at play here, leading to different independent values for key_to_marker. Is that possible? Regards Abhishek -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
