[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] Lock Resources



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

> Ja S wrote:
> > --- Christine Caulfield <ccaulfie redhat com>
> wrote:
> > 
> > 
> >>> DLM lockspace 'data'
> >>>        5         2f06768 1
> >>>        5          114d15 1
> >>>        5          120b13 1
> >>>        5         5bd1f04 1
> >>>        3          6a02f8 2
> >>>        5          cb7604 1
> >>>        5          ca187b 1
> >>>
> >> The first two numbers are the lock name. Don't
> ask
> >> me what they mean,
> >> that's a GFS question! (actually, I think inode
> >> numbers might be
> >> involved) The last number is the nodeID on which
> the
> >> lock is mastered.
> > 
> > 
> > Great, thanks again!
> > 
> > 
> >>>> That lookup only happens the first time
> >>>> a resource is used by a node, once the
> >>>> node knows where the master is, 
> >>>> it does not need to look it up again,
> >>>> unless it releases all
> >>>> locks on the resource.
> >>>>
> >>> Oh, I see. Just to further clarify, does it
> means
> >> if
> >>> the same lock resource is required again by an
> >>> application on the node A, the node A will go
> >> straight
> >>> to the known node (ie the node B) which holds
> the
> >>> master previously, but needs to lookup again if
> >> the
> >>> node B has already released the lock resource?
> >> Not quite. A resource is mastered on a node for
> as
> >> long as there are
> >> locks for it. If node A gets the lock (which is
> >> mastered on node B) then
> >> it knows always to go do node B until all locks
> on
> >> node A are released.
> >> When that happens the local copy of the resource
> on
> >> node A is released
> >> including the reference to node B. If all the
> locks
> >> on node B are
> >> released (but A still has some) then the resource
> >> will stay mastered on
> >> node B and nodes that still have locks on that
> >> resource will know where
> >> to find it without a directory lookup.
> >>
> > 
> > Aha, I think I missed another important concept --
> a
> > local copy of lock resources. I did not realise
> the
> > existence of the local copy of lock resources.
> Which
> > file should I check to figure out how many local
> > copies a node has and what the local copies are? 
> 
> All the locks are displayed in
> /proc/cluster/dlm_locks, that shows you
> which are local copies and which are masters.


A couple of further questions about the master copy of
lock resources.

The first one:
=============

Again, assume:
1) Node A is extremely too busy and handle all
requests
2) other nodes are just idle and have never handled
any requests

According to the documents, Node A will hold all
master copies initially. The thing I am not aware of
and unclear is whether the lock manager will evenly
distribute the master copies on Node A to other nodes
when it thinks the number of master copies on Node A
is too many?


The second one:
==============

Assume a master copy of lock resource is on Node A.
Now Node B holds a local copy of the lock resource.
When the lock queues changed on the local copy on Node
B, will the master copy on Node A be updated
simultaneously? If so, when more than one nodes have
the local copy of the same lock resource, how the lock
manager to handle the update of the master copy? Using
another lock mechanism to prevent the corruption of
the master copy?


Thanks again in advance.

Jas
 


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



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]