From mboxrd@z Thu Jan 1 00:00:00 1970 From: Goldwyn Rodrigues Date: Tue, 05 Nov 2013 14:34:55 -0600 Subject: [Ocfs2-devel] [PATCH 2/6] Add DLM recovery callbacks In-Reply-To: <20131104220936.GP29346@wotan.suse.de> References: <20131018144520.GA4579@shrek.lan> <20131103221644.GH29346@wotan.suse.de> <52771845.2040808@suse.de> <20131104220936.GP29346@wotan.suse.de> Message-ID: <5279566F.7030507@suse.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ocfs2-devel@oss.oracle.com On 11/04/2013 04:09 PM, Mark Fasheh wrote: > On Sun, Nov 03, 2013 at 09:45:09PM -0600, Goldwyn Rodrigues wrote: >> On 11/03/2013 04:16 PM, Mark Fasheh wrote: >>> This also looks good in that I don't see anything wrong with the way the >>> actual code functions. The extra description you put about the callbacks >>> helps in understanding this too. Question - can you explain why oc_this_node >>> is an atomic? That is to say I'd like to understand that race that you're >>> protecting against :) >>> --Mark >> >> Ok, we may not require this to be atomic. The dlm thread sets up >> oc_this_node via .recover_done(), but it should not matter because >> this_node() functions are called after .cluster_connect(). > > Ahh alright. And this is probably a silly question, but we know the dlm will > never call this code concurently? It may.. in case of failure. However, the node number will not change unless the user has forced it. So, I suppose it is best to keep it atomic. I think thats the reason I had kept it atomic initially. -- Goldwyn