Hello, Christine and Ja S. I've been following this thread, because I need, like Ja, a detailed knowledge of the DLM inner workings. Your explanations were detailed and clear, Christine, but, just for the sake of having it documented, do you know where I can download a white paper or article telling this whole story? Thanks in advance Best, Oliveiros <div class="gmail_quote">2008/5/13 Christine Caulfield <<a href="mailto:ccaulfie@redhat.com">ccaulfie@redhat.com</a>>: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div><div></div><div class="Wj3C7c">Ja S wrote: > --- Christine Caulfield <<a href="mailto:ccaulfie@redhat.com">ccaulfie@redhat.com</a>> wrote: > >> Ja S wrote: >>> --- Christine Caulfield <<a href="mailto:ccaulfie@redhat.com">ccaulfie@redhat.com</a>> >> wrote: >>>> Ja S wrote: >>>>> Hi, All: >>>>> >>>>> >>>>> When an application on a cluster node A needs to >>>>> access a file on a SAN storage, how DLM process >>>> the >>>>> lock request? >>>>> >>>>> Should DLM firstly determine whether there >> already >>>>> exists a lock resource mapped to the file, by >>>> doing >>>>> the following things in the order 1) looking at >>>> the >>>>> master lock resources on the node A, 2) >> searching >>>> the >>>>> local copies of lock resources on the node A, 3) >>>>> searching the lock directory on the node A to >> find >>>> out >>>>> whether a master lock resource assosicated with >>>> the >>>>> file exists on another node, 4) sending messages >>>> to >>>>> other nodes in the cluster for the location of >> the >>>>> master lock resource? >>>>> >>>>> I ask this question because from some online >>>> articles, >>>>> it seems that DLM will always search the >>>> cluster-wide >>>>> lock directory across the whole cluster first >> to >>>> find >>>>> the location of the master lock resource. >>>>> >>>>> Can anyone kindly confirm the order of processes >>>> that >>>>> DLM does? >>>>> >>>> This should be very well documented, as it's >> common >>>> amongst DLM >>>> implementations. >>>> >>> I think I may be blind. I have not yet found a >>> document which describes the sequence of processes >> in >>> a precise way. I tried to read the source code but >> I >>> gave up due to lack of comments. >>> >>> >>>> If a node needs to lock a resource that it >> doesn't >>>> know about then it >>>> hashes the name to get a directory node ID, than >>>> asks that node for the >>>> master node. if there is no master node (the >>>> resource is not active) >>>> then the requesting node is made master >>>> >>>> if the node does know the master, (other locks on >>>> the resource exist) >>>> then it will go straight to that master node. >>> >>> Thanks for the description. >>> >>> However, one point is still not clear to me is how >> a >>> node can conclude whether it __knows__ the lock >>> resource or not? >> A node knows the resource if it has a local copy. >> It's as simple as that. >> > > If the node is a human and has a brain, it can > "immediately" recall that it knows the lock resouce. > However, for a computer program, it does not "know" > anything until it search the target in what it has on > hand. > > Therefore, the point here is the __search__. What > should the node search and in which order, and how it > searches? > > If I missed anything, please kindly point out so that > I can clarify my question as clear as possible. > > </div></div>I think you're trying to make this more complicated than it is. As I've said several times now, a node "knows" a resource if there is a local lock on it. That's it! It's not more or less difficult than that, really it isn't! 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. (As I'm sure you already know, locks are known by their lock ID numbers, so there's no "search" involved there either). There is no "search" for a lock around the cluster, that's what the directory node provides. And as I have already said, that is located by hashing the resource name to yield a node ID. So, if you like, the "search" you seem to be looking for is simply a hash of the resource name. But it's not really a search, and it's only invoked when the node first encounters a resource. <div><div></div><div class="Wj3C7c"> Chrissie -- Linux-cluster mailing list <a href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/linux-cluster" target="_blank">https://www.redhat.com/mailman/listinfo/linux-cluster</a> </div></div></blockquote></div>