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