[Cluster-devel] [PATCH] GFS2: kernel changes to support new gfs2_grow command (Try 3)
David Teigland
teigland at redhat.com
Fri May 4 22:16:55 UTC 2007
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
More information about the Cluster-devel
mailing list