Re: RGW Multisite delete wierdness

[Abhishek Lekshmanan <abhishek@suse.com>]

[..]
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