On Tue, Sep 21, 2010 at 11:13 AM, Alain.Moulle <[email protected]> wrote: > Hi Andrew, > > sorry but I don't fully understand : > > - I don't think there is any "fencing" functionnality in the OCFS2 > management,
there is suicide, but that is unrelated to my point > so for me the membership information remains only at > Pacemaker/corosync level. no, ocfs2 also has its own notion of who its peers are - how else does it know who to talk to. > > - I want all the FS OCFS2 always mounted on both sides , so from Pacemaker > point of view, I think that it is like any other File System type > (thanks to OCF > script Filesystem), except that I configure a clone FS, just to be > able to configure > colocation for other primitives on theses clone-FS > > - and so, if one side fails, the clone FS ocfs2 are Stopped on this side but > remain started on the other side. > > So where, in this configuration, is exactly hidden the problem that you > mention ? > > Thanks > Alain > > >> > My choice was to let OCFS2 stack out of Pacemaker configuration, >> > so I let the services o2cb and ocfs2 started at boot time. >> >> Terrible idea sorry. You _really_ dont want two parts of the same >> cluster using different membership information. > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems > _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
