Hi Frédéric, 5a section states that that the divergent events would be tracked and deleted. But in the scenario I’ve mentioned, both B and C will have same history. So if the new primary is B, then when peering, it peers with C and looks at the history and thinks they’ve no divergent events and keep the object right? Regards, Vigneshwar On Wed, 23 Oct 2024 at 9:09 AM, Frédéric Nass < frederic.nass@univ-lorraine.fr> wrote:
Hi Vigneshwar,
You might want to check '5a' section from the peering process documentation [1].
Regards, Frédéric.
[1] https://docs.ceph.com/en/reef/dev/peering/#description-of-the-peering-proces...
------------------------------ *De :* Vigneshwar S <svigneshj@gmail.com> *Envoyé :* mardi 22 octobre 2024 11:05 *À :* ceph-users@ceph.io *Objet :* [ceph-users] How Ceph cleans stale object on primary OSD failure?
Hi everyone, I'm studying Ceph replication and peering and have a doubt in how Ceph handles cleaning of stale objects on primary OSD failure.
Scenario:
Consider a placement group: PG1, whose acting set is [A, B, C] and A is the primary.
t1: Client writes an object to A t2: A initiates local write t3: A sends replication request to B t4: A sends replication request to C t5: A completes local write t6: A gets replication response from B t7: A gets replication response from C t8: A is crashed and haven't sent acknowledgement to the client
In case if A never comes back, the object written in B and C would be stale as it is not acknowledged to the client. How does Ceph cleans this stale object?
Also, it would be helpful if you can share any documentation or articles explaining Ceph replication and peering in low-level.
Regards, Vigneshwar. _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io