From: David Teigland <teigland@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] Question on LVB when the node that held EX lock crash
Date: Wed, 30 Nov 2016 10:16:24 -0600 [thread overview]
Message-ID: <20161130161624.GB27906@redhat.com> (raw)
In-Reply-To: <23125eeb-c185-aca2-b852-edea35765713@suse.com>
On Wed, Nov 30, 2016 at 05:07:22PM +0800, Eric Ren wrote:
> @@ -852,12 +868,19 @@ void dlm_recover_rsbs(struct dlm_ls *ls)
> if (is_master(r)) {
> if (rsb_flag(r, RSB_RECOVER_CONVERT))
> recover_conversion(r);
> +
> + /* recover lvb before granting locks so the updated
> + lvb/VALNOTVALID is presented in the completion */
> + recover_lvb(r);
> +
> if (rsb_flag(r, RSB_NEW_MASTER2))
> recover_grant(r);
> - recover_lvb(r);
> count++;
> + } else {
> + rsb_clear_flag(r, RSB_VALNOTVALID);
> }
> """
>
> 3) Questions:
>
> a. Should we put recover_lvb() even before recover_conversion()? if not, why?
Yes, I think you're right. The lvb decision should be made using the
original lock modes, not the modified lock modes from recover_conversion.
> b. Why should we clear fag RSB_VALNOTVALID in the else branch?
That looks incorrect also. I think VALNOTVALID should only be cleared
when the lvb is written by the application. The else condition should
probably just be removed. That does raise the question of whether it
could be masking another problem (e.g. some case where the flag is not
being cleared when it should be, or a case where it's being set and
shouldn't be.)
Dave
next prev parent reply other threads:[~2016-11-30 16:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-16 8:29 [Cluster-devel] Question on LVB when the node that held EX lock crash Eric Ren
2016-11-16 8:42 ` Eric Ren
2016-11-16 15:08 ` David Teigland
2016-11-17 9:30 ` Eric Ren
2016-11-30 9:07 ` Eric Ren
2016-11-30 16:16 ` David Teigland [this message]
2016-12-01 9:51 ` Eric Ren
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=20161130161624.GB27906@redhat.com \
--to=teigland@redhat.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.