From: Alex Elder <elder@inktank.com>
To: Sage Weil <sage@inktank.com>
Cc: ceph-devel@vger.kernel.org
Subject: Re: [PATCH 5/9] libceph: resubmit linger ops when pg mapping changes
Date: Mon, 30 Jul 2012 17:40:02 -0500 [thread overview]
Message-ID: <50170D42.5060705@inktank.com> (raw)
In-Reply-To: <1342831308-18815-6-git-send-email-sage@inktank.com>
On 07/20/2012 07:41 PM, Sage Weil wrote:
> The linger op registration (i.e., watch) modifies the object state. As
> such, the OSD will reply with success if it has already applied without
> doing the associated side-effects (setting up the watch session state).
> If we lose the ACK and resubmit, we will see success but the watch will not
> be correctly registered and we won't get notifies.
>
> To fix this, always resubmit the linger op with a new tid. We accomplish
> this by re-registering as a linger (i.e., 'registered') if we are not yet
> registered. Then the second loop will treat this just like a normal
> case of re-registering.
>
> This mirrors a similar fix on the userland ceph.git, commit 5dd68b95, and
> ceph bug #2796.
>
> Signed-off-by: Sage Weil <sage@inktank.com>
I have two minor comments below. I confess I don't enough about what's
going on conceptually here to offer a high quality review. However the
change seems be doing what you say is needed, so I guess I'll say it
looks OK to me. Please try to get another reviewer to sign off though.
Reviewed-by: Alex Elder <elder@inktank.com>)
> ---
> net/ceph/osd_client.c | 26 +++++++++++++++++++++-----
> 1 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/net/ceph/osd_client.c b/net/ceph/osd_client.c
> index 07920ca..c605705 100644
> --- a/net/ceph/osd_client.c
> +++ b/net/ceph/osd_client.c
> @@ -891,7 +891,9 @@ static void __register_linger_request(struct ceph_osd_client *osdc,
> {
> dout("__register_linger_request %p\n", req);
> list_add_tail(&req->r_linger_item, &osdc->req_linger);
> - list_add_tail(&req->r_linger_osd, &req->r_osd->o_linger_requests);
> + if (req->r_osd)
> + list_add_tail(&req->r_linger_osd,
> + &req->r_osd->o_linger_requests);
> }
>
> static void __unregister_linger_request(struct ceph_osd_client *osdc,
> @@ -1305,8 +1307,9 @@ static void kick_requests(struct ceph_osd_client *osdc, int force_resend)
>
> dout("kick_requests %s\n", force_resend ? " (force resend)" : "");
> mutex_lock(&osdc->request_mutex);
> - for (p = rb_first(&osdc->requests); p; p = rb_next(p)) {
> + for (p = rb_first(&osdc->requests); p; ) {
> req = rb_entry(p, struct ceph_osd_request, r_node);
> + p = rb_next(p);
Why is this hunk necessary? Can the request's rb pointer(s)
get updated somehow via __map_request() or something?
> err = __map_request(osdc, req, force_resend);
> if (err < 0)
> continue; /* error */
> @@ -1314,10 +1317,23 @@ static void kick_requests(struct ceph_osd_client *osdc, int force_resend)
> dout("%p tid %llu maps to no osd\n", req, req->r_tid);
> needmap++; /* request a newer map */
> } else if (err > 0) {
> - dout("%p tid %llu requeued on osd%d\n", req, req->r_tid,
> - req->r_osd ? req->r_osd->o_osd : -1);
> - if (!req->r_linger)
> + if (!req->r_linger) {
> + dout("%p tid %llu requeued on osd%d\n", req,
> + req->r_tid,
> + req->r_osd ? req->r_osd->o_osd : -1);
> req->r_flags |= CEPH_OSD_FLAG_RETRY;
> + }
> + }
> + if (req->r_linger && list_empty(&req->r_linger_item)) {
> + /*
> + * register as a lingkker so that we will
^^
Is this the Swedish spelling?
> + * re-submit below and get a new tid
> + */
> + dout("%p tid %llu restart on osd%d\n",
> + req, req->r_tid,
> + req->r_osd ? req->r_osd->o_osd : -1);
> + __register_linger_request(osdc, req);
> + __unregister_request(osdc, req);
> }
> }
>
>
next prev parent reply other threads:[~2012-07-30 22:40 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-21 0:41 [PATCH 0/9] messenger fixups, batch #1 Sage Weil
2012-07-21 0:41 ` [PATCH 1/9] libceph: move feature bits to separate header Sage Weil
2012-07-24 22:14 ` Yehuda Sadeh
2012-07-30 18:29 ` Alex Elder
2012-07-21 0:41 ` [PATCH 2/9] libceph: support crush tunables Sage Weil
2012-07-24 22:24 ` Yehuda Sadeh
2012-07-30 23:14 ` Sage Weil
2012-07-30 23:45 ` Yehuda Sadeh
2012-07-30 18:36 ` Alex Elder
2012-07-21 0:41 ` [PATCH 3/9] libceph: report socket read/write error message Sage Weil
2012-07-24 22:26 ` Yehuda Sadeh
2012-07-30 18:37 ` Alex Elder
2012-07-21 0:41 ` [PATCH 4/9] libceph: fix mutex coverage for ceph_con_close Sage Weil
2012-07-24 22:29 ` Yehuda Sadeh
2012-07-30 18:43 ` Alex Elder
2012-07-21 0:41 ` [PATCH 5/9] libceph: resubmit linger ops when pg mapping changes Sage Weil
2012-07-24 22:51 ` Yehuda Sadeh
2012-07-30 22:40 ` Alex Elder [this message]
2012-07-30 23:03 ` Sage Weil
2012-07-21 0:41 ` [PATCH 6/9] libceph: (re)initialize bio_iter on start of message receive Sage Weil
2012-07-24 22:55 ` Yehuda Sadeh
2012-07-30 19:04 ` Alex Elder
2012-07-21 0:41 ` [PATCH 7/9] ceph: close old con before reopening on mds reconnect Sage Weil
2012-07-24 22:56 ` Yehuda Sadeh
2012-07-30 23:11 ` Sage Weil
2012-07-21 0:41 ` [PATCH 8/9] libceph: protect ceph_con_open() with mutex Sage Weil
2012-07-24 22:58 ` Yehuda Sadeh
2012-07-30 19:06 ` Alex Elder
2012-07-21 0:41 ` [PATCH 9/9] libceph: reset connection retry on successfully negotiation Sage Weil
2012-07-24 23:00 ` Yehuda Sadeh
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=50170D42.5060705@inktank.com \
--to=elder@inktank.com \
--cc=ceph-devel@vger.kernel.org \
--cc=sage@inktank.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox