From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell Cattelan Date: Wed, 31 Jan 2007 18:46:14 -0600 Subject: [Cluster-devel] Fix for unlink deadlock In-Reply-To: <1170289078.3832.5.camel@localhost.localdomain> References: <1170112424.28100.124.camel@xenon.msp.redhat.com> <1170163127.11001.164.camel@quoit.chygwyn.com> <1170289078.3832.5.camel@localhost.localdomain> Message-ID: <1170290775.432.16.camel@xenon.msp.redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, 2007-01-31 at 19:17 -0500, Wendy Cheng wrote: > On Tue, 2007-01-30 at 13:18 +0000, Steven Whitehouse wrote: > > Hi, > > > > On Mon, 2007-01-29 at 17:13 -0600, Russell Cattelan wrote: > > > Note the current glock code in the tree is completely busted > > > and will dead lock almost immediately. > > > > > > I have reverted several changes to glock.c and have > > > tested this patch with the older glock code. > > > dbench will now run through to completion. > > > > > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217356 > > > > Now applied to the -nmw git tree. > > hmm.. just untar Steve's git tree he sent me this morning few minutes > ago and spot this - sorry I should have read this post earlier ... Look > to me this will deadlock gfs2_rename() *again* (since it tries to grab > rindex lock multiple times). Will test this out tomorrow when I get the > connectathon cluster up. > I never understood what sequence of events that you found that would cause the recursive locking, but I tried to set it up such that rename will only grab the rsgr lock once and outside log locks. I tested the touch foo foo1 ; mv foo foo1 scenario and it works. > > -- Wendy > > > > I think the way to get around the > > problem with not knowing whether the link count will hit zero is just to > > remove the code which changes the link count from gfs2_change_nlink and > > to turn that into a function which just syncs the current link count to > > the on-disk inode. > > > > It would also solve the problem of needing to work out whether to use > > inc_nlink() or dec_nlink() to make the change to the link count. Due to > > the forthcoming read-only bind mounts work, we must always use the > > macros to change the link count rather than doing it directly. > > > > Steve. > > > > -- Russell Cattelan