| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
Don, Daniel's explanation matches our own usage of the Tru64 DLM. Dead man locks were almost the secondary method of detecting node failure, since it was more likely to see an invalid lock block on some other random pending request first. Dead man locks were useful so we could always detect failure even in the exception case where there was no pending lock activity for a resource on the failed node(s), and to prevent a failed node from immediately bouncing back up until our apps on the other nodes had performed application recovery on the failed nodes behalf. My recollection is that the information re the persistent locks was not fully replicated. Compaq had provided a tool to dump their view of the locks, and I'm 99.44% certain that was the case. Unfortunately, I no longer have access to a Tru64 cluster to confirm this. Jack Devine john.devine@xxxxxx -----Original Message----- From: Zickus II, Don Sent: Thursday, April 29, 2004 8:49 PM To: Devine, John T Subject: FW: [ogfs-dev]RE: [Opendlm-devel] ODLM/OGFS Recovery Does this ring any bells from your tru64 days? -Don -----Original Message----- From: opendlm-devel-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:opendlm-devel-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Daniel McNeil Sent: Thursday, April 29, 2004 8:38 PM To: opengfs-devel@xxxxxxxxxxxxxxxxxxxxx Cc: opendlm-devel@xxxxxxxxxxxxxxxxxxxxx Subject: RE: [ogfs-dev]RE: [Opendlm-devel] ODLM/OGFS Recovery On Thu, 2004-04-29 at 09:18, Zickus II, Don wrote: > Hello Stan, > > We actually used this function on trucluster. However, its main use > was _after_ detection of a failed node and even then to revalidate > the lock value blocks and resources assuming you are using lock value > blocks. > > I have thinking about this whole problem and wondering what everyone's > definition of 'persistent' lock is? Is it expected to have every > resource and its information replicated across the entire cluster or > just have each node keep track of its own resource locks? > > -Don > This is the same question I had many years ago when I first heard about persistent locking. As I have said before, a particular implementation of persistent locking was used to implement a cluster file system. >From what I remember (It has been more than 4 years since I worked on this). As it was explained to me, the whole point of persistent locks was that the application did not want to keep a bunch of locks open to be able to find out that some event has occurred which would require an application recovery before using the lock. Previously, the application would keep the locks open and if it got a invalid value block back, it would know that a recovery is required. With "persistent" locks, the application did not have to keep the lock open, but would still get the invalid value block if process holding the lock died or a node died. Re-reading the trucluster man pages I pointed to before (like this one): http://h30097.www3.hp.com/docs/cluster_doc/cluster_16/MAN/MAN3/0021____. HTM This implementation seems much more complicated than what I remember. This looks like this DLM does keep persistent locks around if they are invalid after the process closes them (and they get marked invalid if a node dies). Thus, a new lock request will see the invalid lock even when all previous users have gone away. I'm guessing that is what is meant by persistent. The more simple implementation approach I remember (as best as I can -- at least for the node death case anyway -- and it really isn't that simple). If a node dies, then all new persistent locks would return invalid until the dlm_rd_validate() is made. Also, existing dlm locks could get marked invalid during dlm recovery. This implementation was then used to implement CFS. Recovery went something like: running nomally node dies DLM recovery runs - non-persistent locks recover persistent locks return invalid deadman locks from dead node(s) for each file system are granted start file system recovery: surviving nodes pick one to run log replay id = dlm_attach() replay file system log if validate(id) == MORE_RECOVERY re-start file system recovery since there's been another death dlm_validate(id) - persistent locks valid now other surviving nodes wait for replay file system recovery complete if another node dies in the middle of file system recovery abort current recovery and start over This is simpler because persistent locks returned invalid based on whether a node died until the validate call was made. Every node in the cluster did not have to replicated each lock information. The use of persistent locks prevented surviving nodes from accessing metadata BEFORE file system log replay had finished. We used separate lock domains for each file system, so file system recovery happened in parallel. Sorry for rambling, but I think I answered the question in there somewhere. Daniel ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Opendlm-devel mailing list Opendlm-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/opendlm-devel ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id?66&opÌk _______________________________________________ Opengfs-devel mailing list Opengfs-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/opengfs-devel