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

[Ja S]

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

> Ja S wrote:
> > --- 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?) ?
> >
> 
> No, that's correct. It's missing a lot of detail,
> but the overview is fair.
> 
> There's a conflation you've done there that is OK
> for a simplisitic
> discussion of GFS but hides an important
> abstraction.
> 
> The DLM does not deal in inode numbers, it only
> deals in resource names.
> The application that uses the DLM (this includes
> GFS) decides what the
> resource names are. GFS uses some system I don't
> know about but looks
> like it might include the inode number. clvmd (for
> example) uses LV
> UUIDs or VG names for its resource names for
> instance.
> 
> These resources are isolated from each other in
> separate lockspaces.
> Lockspace is a mandatory parameter to all locking
> calls.

Clear. Great thanks to your detailed explanation.

All the best,

Jas