From: xxhdx1985126 <xxhdx1985126@163.com>
To: "ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>
Subject: How does rbd-mirror preserve the order of WRITE operations that finished on the primary cluster
Date: Mon, 5 Jun 2017 12:05:26 +0800 (CST) [thread overview]
Message-ID: <70c5c552.66e6.15c766dce68.Coremail.xxhdx1985126@163.com> (raw)
Hi, everyone.
Recently, I've been reading the source code of rbd-mirror. I wonder how rbd-mirror preserves the order of WRITE operations that finished on the primary cluster. As far as I can understand the code, rbd-mirror fetches I/O operations from the journal on the primary cluster, and replay them on the slave cluster without checking whether there's already any I/O operations targeting the same object that has been issued to the slave cluster and not yet finished. Since concurrent operations may finish in a different order than that in which they arrived at the OSD, the order that the WRITE operations finish on the slave cluster may be different than that on the primay cluster. For example: on the primary cluster, there are two WRITE operation targeting the same object A which are, in the order they finish on the primary cluster, "WRITE A.off data1" and "WRITE A.off data2"; while when they are replayed on the slave cluster, the order may be "WRITE A.off data2" and "WRITE A.off data1", which means that the result of the two operations on the primary cluster is A.off=data2 while, on the slave cluster, the result is A.off=data1.
Is this possible?
next reply other threads:[~2017-06-05 4:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-05 4:05 xxhdx1985126 [this message]
2017-06-05 12:00 ` How does rbd-mirror preserve the order of WRITE operations that finished on the primary cluster Jason Dillaman
2017-06-05 15:49 ` xxhdx1985126
2017-06-05 16:21 ` Sage Weil
[not found] ` <428d3e79.3d2.15c7a56a64f.Coremail.xxhdx1985126@163.com>
2017-06-05 22:22 ` Sage Weil
2017-06-05 22:50 ` xxhdx1985126
2017-06-06 3:04 ` xxhdx1985126
2017-06-06 3:13 ` Haomai Wang
2017-06-06 4:05 ` xxhdx1985126
2017-06-06 7:34 ` xxhdx1985126
2017-06-06 7:40 ` xxhdx1985126
2017-06-06 7:49 ` Haomai Wang
2017-06-06 8:07 ` xxhdx1985126
2017-06-06 11:20 ` Jason Dillaman
2017-06-14 2:03 ` xxhdx1985126
[not found] ` <47d3f4bc.3a4b.15c7b3fceb0.Coremail.xxhdx1985126@163.com>
2017-06-06 14:01 ` Sage Weil
2017-06-07 15:36 ` xxhdx1985126
2017-06-07 15:42 ` xxhdx1985126
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=70c5c552.66e6.15c766dce68.Coremail.xxhdx1985126@163.com \
--to=xxhdx1985126@163.com \
--cc=ceph-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.