[Cluster-devel] [GFS2 PATCH]

[Steven Whitehouse <swhiteho@redhat.com>]

Hi,

On Fri, 2012-02-17 at 09:34 -0500, Bob Peterson wrote:
> ----- Original Message -----
> | Hi,
> | 
> | If we are going to do this, then perhaps we should consider reading
> | in
> | the rindex on mount? That way it will always be uptodate, and we can
> | refuse to mount if the rindex is damaged which is probably cleaner
> | than
> | doing it after the event.
> | 
> | The only concern is the time taken to mount large filesystems. Having
> | said that the rindex should be contiguous on disk in most cases, so
> | it
> | should be a fairly fast operation. Worth considering, anyway I think,
> | 
> | Steve.
> 
> Hi,
> 
> That's not a bad idea, and we should consider it for a future enhancement.
> However, I think these checks still need to be here because there are
> other ways the rindex can get out of date and need to be re-read after
> mount. For example, if there was another intermediate gfs2_grow done on a
> different node.
> 
There is no locking here to prevent the rindex from becoming out of date
again, immediately after this call, so that might still be picked up by
he lower level code and result in another problem if I'm reading the
original bug report correctly.

An alternative way to resolve this is just to check whether the rindex
is already locked before trying to lock it again at the lower level. Or,
I guess, we could even do both.

> BTW, I assume you saw my other patch from yesterday regarding gfs2_unlink, right?
> 
> Regards,
> 
> Bob Peterson
> Red Hat File Systems

Yes, I was just about to take a look at it - I've been a little waylaid
with other things in the last couple of days,

Steve.