[Linux-cluster] Locks reported by gfs_tool lockdump does not match that presented in dlm_locks. Any reason??

[Ja S]

--- Wendy Cheng <s.wendy.cheng at gmail.com> wrote:

> Ja S wrote:
> > Hi, All:
> >
> > For a given lock space, at the same time, I saved
> a
> > copy of the output of “gfs_tool lockdump?as
> > “gfs_locks?and a copy of dlm_locks. 
> >
> > Then I checked the locks presents in the two saved
> > files. I realized that the number of locks in
> > gfs_locks is not the same as the locks presented
> in
> > dlm_locks.
> >
> > For instance, 
> > >From dlm_locks:
> > 9980 NL locks, where
> > --7984 locks are from remote nodes
> > --0 locks are on remote nodes
> > --1996 locks are processed on its own master lock
> > resources
> > 0 CR locks, where
> > --0 locks are from remote nodes
> > --0 locks are on remote nodes
> > --0 locks are processed on its own master lock
> > resources
> > 0 CW locks, where
> > --0 locks are from remote nodes
> > --0 locks are on remote nodes
> > --0 locks are processed on its own master lock
> > resources
> > 1173 PR locks, where
> > --684 locks are from remote nodes
> > --32 locks are on remote nodes
> > --457 locks are processed on its own master lock
> > resources
> > 0 PW locks, where
> > --0 locks are from remote nodes
> > --0 locks are on remote nodes
> > --0 locks are processed on its own master lock
> > resources
> > 47 EX locks, where
> > --46 locks are from remote nodes
> > --0 locks are on remote nodes
> > --1 locks are processed on its own master lock
> > resources
> >
> > In summary, 
> > 11200 locks in total, where
> > -- 8714 locks are from remote nodes (entries with
> ?> > Remote: ?
> > -- 32 locks are on remote nodes (entries with ?> >
Master: ?
> > -- 2454 locks are processed on its own master lock
> > resources (entries with only lock ID and lock
> mode)
> >
> > These locks are all in the granted queue. There is
> > nothing under the conversion and waiting queues.
> > ======================================
> >
> > >From gfs_locks, there are 2932 locks in total, (
> grep
> > ‘^Glock ?and count the entries). Then for each
> Glock
> > I got the second number which is the ID of a lock
> > resource, and searched the ID in dlm_locks. I then
> > split the searched results into two groups as
> shown
> > below:
> > --46 locks are associated with local copies of
> master
> > lock resources on remote nodes
> > --2886 locks are associated with master lock
> resources
> > on the node itself
> >
> >
> > ======================================
> > Now, I tried to find the relationship between the
> five
> > numbers from two sources but ended up nowhere.
> > Dlm_locks:
> > -- 8714 locks are from remote nodes 
> > -- 32 locks are on remote nodes
> > -- 2454 locks are processed on its own master lock
> > resources 
> > Gfs_locks:
> > --46 locks are associated with local copies of
> master
> > lock resources on remote nodes
> > --2886 locks are associated with master lock
> resources
> > on the node itself
> >
> > Can anyone kindly point out the relationships
> between
> > the number of locks presented in dlm_locks and
> > gfs_locks?
> >
> >
> > Thanks for your time on reading this long question
> and
> > look forward to your help.
> >
> >   
> I doubt this will help anything from practical point
> of view.. 
> understanding how to run Oprofile and/or SystemTap
> will probably help 
> you more on the long run. However, if you want to
> know .. the following 
> are why they are different:
> 
> GFS locking is controlled by a subsysgtem called
> "glock". Glock is 
> designed to run and interact with *different*
> distributed lock managers; 
> e.g. in RHEL 3, other than DLM, it also works with
> another lock manager 
> called "GULM". Only active locks has an one-to-one
> correspondence with 
> the lock entities inside lock manager. If a glock is
> in UNLOCK state, 
> lock manager may or may not have the subject lock in
> its record - they 
> are subject to get purged depending on memory and/or
> resource pressure. 
> The other way around is also true. A lock may exist
> in lock manager's 
> database but it could have been removed from glock
> subsystem. Glock 
> itself doesn't know about cluster configuration so
> it relies on external 
> lock manager to do inter-node communication. On the
> other hand, it 
> carries some other functions such as data flushing
> to disk when glock is 
> demoted from exclusive (write) to shared (read).


Thanks for the explanation. It is very helpful.

Jas


> -- Wendy
> 
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
>
https://www.redhat.com/mailman/listinfo/linux-cluster
>