[Cluster-devel] cluster/gfs-kernel/src/gfs inode.h ops_export.c

[Steven Whitehouse <swhiteho@redhat.com>]

Hi,

On Wed, 2007-01-17 at 18:05 -0500, Wendy Cheng wrote:
> Steven Whitehouse wrote:
> > Hi,
> >
> > Just wondering why this:
> >
> > On Tue, 2007-01-16 at 20:39 +0000, wcheng at sourceware.org wrote:
> > [snip]
> >> -
> >>  	error = gfs_glock_nq_num(sdp,
> >> -				 inum.no_formal_ino, &gfs_inode_glops,
> >> +				 inum->no_formal_ino, &gfs_inode_glops,
> >>  				 LM_ST_SHARED, LM_FLAG_ANY | GL_LOCAL_EXCL,
> >>  				 &i_gh);
> >>     
> > needs the GL_LOCAL_EXCL flag. I would have thought an ordinary shared
> > lock would be enough?
> >   
> It is required to prevent (by serializing) other process (on the same 
> node) to create this gfs inode at the same time (equivalence of an 
> semaphore or mutex). Lookup (and several other GFS1 mount/umount) code 
> needs this flag too. This (my guess) is to reduce the need to create 
> another set of semaphores/mutex. In summary, I think it has two advantages:
> 1. Less locks
> 2. Easier to track who owns what (since glock holder is easy to find 
> when compared with sempahore/mutex).
> 
Ah, that kind of makes sense then for gfs1.

> The down-side is that it makes glock code difficult to understand.  For 
> GFS1, let's keep it this way. For GFS2,  your call :) ...
> 
Yes, I don't want to go changing things like that in GFS1 at all :-) In
GFS2 we use the inode cache as its supposed to be used and that deals
with all the required local serialisation, so it looks to be redundant
in that case.

Also in more recent kernels, lockdep deals with your point #2 above, so
I can't see anything really standing in the way of swapping the few
remaining cases for a mutex or rwsem and glock combination.

In fact one of the reason for doing this is to work towards the
possibility of using lockdep with glocks. Lockdep has no concept of
"local" and "remote" but it does have the concept of nested locks so its
one step closer to being able to make use of that,

Steve.