Hi Sunil,
yes I know about ocfs2.pcmk, but it was absolutely not working
in previous releases, so :
- is this stack ocfs2 for pacemaker maintained , supported ?
- is it really used on some customers clusters ?
Thanks
Regards
Alain
Sunil Mushran a e'crit:
On 02/08/2011 01:32 AM, Alain.Moulle wr
On 02/08/2011 01:32 AM, Alain.Moulle wrote:
> OK but what I wonder now is :
> is OCFS2 really capable of fencing an adjacent node ?
> or is it only capable of "node self-fencing" ?
> I thought that ocfs2 was only capable of "node self-fencing" because
> there is no configuration of any fencing devi
On 02/07/2011 10:41 PM, Mikey Austin wrote:
> We have been using the ocfs2 tools (version 1.4.4) on gentoo (2.6.18-164.15.1
> kernel) for around 6 months now. We would like to re-create all of the ocfs2
> filesystems that were not created with mkfs.ocfs2 version 1.4.4, however we
> are not able to
Hi,
sorry but I don't understand, do you mean that even if the linkcom
problem is only
on node1 side (i.e. if the Eth Board has a breakdown) ,you mean that
this will
lead to a self-fence of node1 whereas it is node 0 which has the real
problem ?
Thanks for this precision
PS : and no, I can't
In a two-node setup, node 0 will survive, because that's the node with the
lowest node number (as defined in cluster.conf).
You may want to think about adding a third [FAKE] node; if this is a
feasible workaround, then only the troublesome node should fence itself.
-Original Message
Hi,
I have give it a try :
linkcom PtP between node1 and node2
IO traffic on OCFS2 on both sides
unplug the PtP cable from both nodes
=>both IO traffic on OCFS2 are stalled
=>after a short while, node2 self-fences,
=>whereas a short while after the self-fence of node2 , IO traffic
on node1 s
And a relative question :
if there is a network breakdown on the only communication link
for ocfs2
in a two-nodes cluster, what is the behavior :
- will both nodes decide to suicide ?
- will both nodes remain alive providing the exchanges of
informations on disk are always wo
