Gitweb: http://git.fedorahosted.org/git/?p=dlm.git;a=commitdiff;h=a9c0eb5fb07f25e36a... Commit: a9c0eb5fb07f25e36a8750abaa2678fd0344ae35 Parent: 23b48a5cf204bee8f362f68733430f5c1330c7d0 Author: David Teigland teigland@redhat.com AuthorDate: Thu Jan 31 16:42:10 2013 -0600 Committer: David Teigland teigland@redhat.com CommitterDate: Thu Jan 31 16:42:10 2013 -0600
dlm_controld: don't nack the first and only cg
I don't think there's any case where we want to nack it, and I observed a case where it was nacked when we didn't want it.
Signed-off-by: David Teigland teigland@redhat.com --- dlm_controld/cpg.c | 16 ++++++++++++++++ 1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/dlm_controld/cpg.c b/dlm_controld/cpg.c index 82dae3d..f971158 100644 --- a/dlm_controld/cpg.c +++ b/dlm_controld/cpg.c @@ -865,6 +865,22 @@ static int match_change(struct lockspace *ls, struct change *cg, if (members_mismatch) return 0;
+ /* Not completely sure if this is a valid assertion or not, i.e. not + sure if we really never want to nack our first and only cg. I have + seen one case in which a node incorrectly accepted nacks for cg seq + 1 and ls change_seq 1. (It was the secondary effect of another bug.) + + Or, it's possible that this should apply a little more broadly as: + don't nack our most recent cg, i.e. cg->seq == ls->change_seq (1 or + otherwise). I'm hoping to find a test case that will exercise this + to clarify the situation here, and then update this comment. */ + + if (cg->seq == 1 && ls->change_seq == 1 && (hd->flags & DLM_MFLG_NACK)) { + log_group(ls, "match_change %d:%u skip cg %u for nack", + hd->nodeid, seq, cg->seq); + return 0; + } + node->last_match_seq = cg->seq;
log_group(ls, "match_change %d:%u matches cg %u", hd->nodeid, seq,
cluster-commits@lists.fedorahosted.org