[Cluster-devel] [PATCH] GFS2: kernel changes to support new gfs2_grow command (Try 3)

[David Teigland <teigland@redhat.com>]

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