From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Teigland Date: Fri, 4 May 2007 17:16:55 -0500 Subject: [Cluster-devel] [PATCH] GFS2: kernel changes to support new gfs2_grow command (Try 3) In-Reply-To: <463BA70C.60507@redhat.com> References: <46394174.2030709@redhat.com> <20070504164735.GC4659@redhat.com> <463BA70C.60507@redhat.com> Message-ID: <20070504221655.GB18019@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 Fri, May 04, 2007 at 04:35:08PM -0500, Robert Peterson wrote: > >>+ if (!gfs2_glock_is_held_excl(ip->i_gl) && > >>+ !gfs2_glock_is_held_shrd(ip->i_gl) && > > > >Be extremely wary of using these "is_held" functions algorithmically; > >needing to use them is usually an indication that you're doing something > >wrong (I'll have to study this case a bit more to say anything helpful). > > I was using these functions to determine if someone was doing > writes to the rindex file through the meta_fs, in which case I > don't want to exit with a consistency error. If the rindex is being > written to, there may be partial pieces of rindex entries > left on a page (i.e. between two gfs2_write_commits) before the > writing is over. In these cases, it's normal and we should ignore > the partial entries (and re-read them when the writing is complete > and the version number has changed). > > My concern here is if a different node decides to do an ri_update > while a gfs2_grow is happening. For example, if someone does a > mount of the file system on a different node, the rindex may > briefly be in an inconsistent state. Why doesn't the exclusive glock held over the update protect against other processes reading something bad? Dave