From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Date: Tue, 07 Aug 2007 16:09:56 +0100 Subject: [Cluster-devel] [GFS2] Don't use journal lock type In-Reply-To: <20070807140209.GB19779@redhat.com> References: <1186478767.8765.708.camel@quoit> <20070807134510.GA19779@redhat.com> <1186494751.8765.713.camel@quoit> <20070807140209.GB19779@redhat.com> Message-ID: <1186499396.8765.717.camel@quoit> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, On Tue, 2007-08-07 at 09:02 -0500, David Teigland wrote: > 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. > I see now! Well spotted, and I'll send a new patch shortly to use the inode's own lock (which is available in both places anyway), Steve.