Putting O2CB Under the GFS2 DLM
The OCFS2 Cluster Base (O2CB) and DLM have certain, shall we say, limitations. Trying to test OCFS2 on top of the entire GFS2 stack, though, would be tough. OCFS2 is strongly tied to the node information and network communication provided by the O2CB stack.
To get around these issues, we're going to take baby steps. The GFS2 DLM is similar to the OCFS2 DLM, and would probably fit pretty easily. However, it relies on the GFS2 node management stack (Cman, et al). Our goal here is to remove this dependancy, providing the GFS2 DLM the information it requires via O2CB.
GFS2's DLM gets its domain information from the group daemon groupd. O2CB has no group daemon. The closest it has to "group" information is the members of a certain heartbeat region. This will work for our task at hand, but we will have to modify the code a little. Currently, if a node is in one heartbeat region, it is considered to be in all regions. The O2CB heartbeat only notifies registrants when a node leaves all regions. In order to function more like a group service, O2CB heartbeat must be modified to notify specific to each region.
Next, we must provide a method for heartbeat to call into the GFS2 DLM's notion of membership. When the O2CB heartbeat sees a new node, it must add it to the GFS2 DLM's list. When a node leaves the heartbeat region, it must be removed from the GFS2 DLM list.
Do these two things, and we have the core of our proposition -- the GFS2 DLM running on top of O2CB.
Jeff Mahoney (Hi Jeff!) has some patches to make notification region specific. We should explore these patches and see if the cover our needs. This may even be a mainline candidate as-is. That's our first point of attack.
After that, we curl into a ball and weep. No, actually we dive into GFS2 DLM code. Whee!
If this works out pretty well, we may try further steps. Bringing OCFS2 on top of this stack is the next obvious choice. OCFS2's dlmglue must be made to work with the GFS2 DLM.
So Where Are We?
Well, the neat part is that pretty much everything in the GFS2 DLM is communicated via events. There is a dlm_controld process that receives events from the DLM itself, cmand, and groupd. We need to take this daemon and give it events corresponding to o2cb actions. I think we can even reuse a lot of the talking-to-the-dlm actions.
That's where I'm at today. The next step is cooking up that connection.