From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14099 invoked by alias); 21 Sep 2006 15:46:54 -0000 Received: (qmail 14082 invoked by uid 9453); 21 Sep 2006 15:46:54 -0000 Date: Thu, 21 Sep 2006 15:46:00 -0000 Message-ID: <20060921154654.14081.qmail@sourceware.org> From: teigland@sourceware.org To: cluster-cvs@sources.redhat.com Subject: cluster/cman-kernel/src sm_message.c Mailing-List: contact cluster-cvs-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: cluster-cvs-owner@sourceware.org X-SW-Source: 2006-q3/txt/msg00662.txt.bz2 List-Id: CVSROOT: /cvs/cluster Module name: cluster Branch: STABLE Changes by: teigland@sourceware.org 2006-09-21 15:46:54 Modified files: cman-kernel/src: sm_message.c Log message: Before choosing a new global id for a new group, a node discovers what the current max group id seen by any node in the cluster is and picks new=max+1. The problem is when two nodes do this in parallel for two different new groups (that are at the same level) and end up assigning the same global id to the two different groups. To fix this, we have a node take this max group id and add its own nodeid to it, so new=max+our_nodeid. This is similar to designating some of the id bits to be the nodeid of the node creating the group, but that method would break backward compatibility. bz 206193 Also, if we reach the max value of the global id counter (0xFFFFFF), then print a message and refuse to go ahead forming the group. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/cman-kernel/src/sm_message.c.diff?cvsroot=cluster&only_with_tag=STABLE&r1=1.4.8.1&r2=1.4.8.2