[Linux-cluster] What is the order of processing a lock request?

[Ja S]

--- Christine Caulfield <ccaulfie at redhat.com> wrote:

> Ja S wrote:
> >>>> If the node doesn't have a local lock on
> >>>> the resource then it
> >>>> doesn't "know" it and has to ask the directory
> >>>> node where it is mastered. 
> > 
> >>> Does it mean even if the node owns the master
> lock
> >>> resource but it doesn't have a local lock
> >>> associated with the master lock resource, it
> >>> still needs to ask the directory node?
> > 
> > 
> >> hash tables, hash tables, hash tables ;-)
> > 
> > Sure. Now I see what do you mean "knows". Thanks.
> > 
> > Could you please kindly answer my last question
> above?
> 
> The answer is "No" ... because it's in the resource
> hash table.
> 
> ... see, I told you it was all hash tables ...
> 

OK. Let's summarise what I have learned from you. If I
am wrong, correct me please.


A node has a hash table (HT1) which hold the master
lock resources and local copies of master lock
resources on remote nodes. It also has another hash
table (HT2) which holds the content of the lock
directory.

When an application on a node A requests a lock on a
file, DLM feeds the inode number of the file into a
hash function and uses the returned hash value to
check whether there is a corresponding lock resource
record in the hash table HT1. If the record exists,
DLM then processes the lock request on the lock
resources (either master or local copy). 

If not, DLM feeds the inode number into another hash
function to obtain a node ID (for example node B)
which holds the master node information of the target
lock resource. DLM then talks with node B and gets the
master node ID (for example node C) from the hash
table HT2 on node B. Finally, DLM gets the target lock
resource from the hash table HT1 on the node C and
processes the lock request.

Am I right this time, or still missing something (a
third hash table?) ?

Best,

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