From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Teigland Date: Tue, 7 Aug 2007 09:02:10 -0500 Subject: [Cluster-devel] [GFS2] Don't use journal lock type In-Reply-To: <1186494751.8765.713.camel@quoit> References: <1186478767.8765.708.camel@quoit> <20070807134510.GA19779@redhat.com> <1186494751.8765.713.camel@quoit> Message-ID: <20070807140209.GB19779@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 Tue, Aug 07, 2007 at 02:52:31PM +0100, Steven Whitehouse wrote: > Hi, > > On Tue, 2007-08-07 at 08:45 -0500, David Teigland wrote: > > On Tue, Aug 07, 2007 at 10:26:06AM +0100, Steven Whitehouse wrote: > > > error = gfs2_glock_nq_num(sdp, sdp->sd_lockstruct.ls_jid, > > > - &gfs2_journal_glops, > > > + &gfs2_inode_glops, > > > LM_ST_EXCLUSIVE, LM_FLAG_NOEXP, > > > &sdp->sd_journal_gh); > > > > The lock for journal N is now the same as the lock for the inode at > > block N -- that doesn't work. > > > > Yes, thats the point of the patch, after all journals are now inodes. If > we don't do that then two things happen: > > - Accesses of the journal inodes via the meta fs will not be "in sync" > with what the kernel sees > - More importantly, and the reason why this patch was created is that > upon recovery of a journal, the cache wasn't being flushed resulting in > the blocks being sometimes "seen" again the next time a node recovers > the same remote journal. The journal with id N does not live in the inode at fs block N. So, you're still using two different locks for the journal, and one of them now collides with something else.