<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1561" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=Arial size=2>Moreover.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>(If we hajacked this thread already, can we proceed
for 1 more day on it?)</FONT></DIV>
<DIV><FONT face=Arial><BR><FONT size=2></FONT></FONT> </DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV><BR><FONT face=Arial size=2>A) the node is well behaving, just loses
connection to part of the<BR>storage - no fencing is needed, you just dont
issue more requests and<BR>remeber the new node state, the other nodes might
recognize<BR>recovery/replay is needed. Nobody (especially not the fencing
node) can<BR>know which part of the last IO transaction will reach the device
(or<BR>not) anyway. Thats why you have to have IO transactions with
atomic<BR>changes and integrity. Also there is no need to dequeue the last
IO<BR>request for exactly that reason - it must not be harmfull
anyway.</FONT></DIV><FONT face=Arial size=2></FONT></BLOCKQUOTE>
<DIV><FONT face=Arial size=2>You can, in such case, ask another nodes to make IO
for you, and it can help in MANY cases (at least it can help to close objects if
necessary).</FONT></DIV>
<DIV><FONT face=Arial size=2>Risk of _pending IO can pass thru_ is sugnificant
in such case no matter how you fence (problem is that if storage wake up
suddenly, it can proceed old</FONT></DIV>
<DIV><FONT face=Arial size=2>writes which have been sent long ago). Fencing may
be necessary if there was (or there is) pending writes (except heartbeats which
should be treated differently) to the file structures (but not to the file
blocks, they are safe from FS point of view).</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>But if you know for sure that all IO passed thru
(and was confirmed) then risk is almost zero and you can avoid fencing.</DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV dir=ltr style="MARGIN-RIGHT: 0px"><BR><BR>B) the node is totally borken
(memory overwrite, interrupt deadlocks,<BR>etc). In that case the note might
not notice the failure, or it might<BR>not be able to self-fence. This is a
typical case for STONIT.<BR></DIV></BLOCKQUOTE>
<DIV dir=ltr style="MARGIN-RIGHT: 0px">Interesting question - does
handcheck_timer helps in such cases?</DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px"> </DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV dir=ltr style="MARGIN-RIGHT: 0px"><BR>C) the node is well just the
heartbeat is delayed, or the overall nodes<BR>are well and the cache is in
sync, only a single disk storage fails.<BR>Those cases should never occur
(larger timeouts are only part of the<BR>solution, a smarter quorum algorithm
like provided with heartbeat or<BR>other cluster managers is needed). That
case was happenign quite often,<BR>I guess increased timeouts make this a bit
better, but cant be reliable<BR>solved with a cluster framework which
considers more thant the state of<BR>of a single network
connection.<BR><BR>One of the Problems OCFSv2 has is, that the condition c)
happened too<BR>often and that the condition a) is not recognizeable. And of
course that<BR>all those conditions are handled in the simplest way, with a
panic which<BR>is IMHO not really helpful for the above mention
reasons.<BR></DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px"> </DIV></BLOCKQUOTE>
<DIV dir=ltr style="MARGIN-RIGHT: 0px">I'd better add 2 more confitions:</DIV>
<DIV dir=ltr
style="MARGIN-RIGHT: 0px"> D) All
nodes lost connection to the storage disk. They should know it from each other
and so wait</DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px"> until at least one
node restore connection (in most cases all nodes will got connection at
once).</DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px"> </DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px"> E)
Node lost all connections to both other nodes and disks. IT can avoid fencing
ONLY if it had not any pending IO for a long.</DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px"> </DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px"> </DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px">Problem is that A) and D) are not
recognized at all, and C) happens too often.</DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px"> </DIV>
<DIV dir=ltr style="MARGIN-RIGHT: 0px"> </DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV dir=ltr style="MARGIN-RIGHT: 0px"><BR>Gruss<BR>Bernd<BR><BR><BR>SEEBURGER
AG <BR>Headquarters:<BR>Edisonstraße 1 <BR>D-75015 Bretten <BR>Tel.: 0 72
52/96-0 <BR>Fax: 0 72 52/96-2222 <BR>Internet: </FONT><A
href="http://www.seeburger.de"><FONT face=Arial
size=2>http://www.seeburger.de</FONT></A><FONT face=Arial size=2> <BR>e-mail:
</FONT><A href="mailto:info@seeburger.de"><FONT face=Arial
size=2>info@seeburger.de</FONT></A><FONT face=Arial size=2>
<BR><BR>Vorstand:<BR>Bernd Seeburger, Axel Haas, Michael
Kleeberg<BR><BR>Vorsitzender des Aufsichtsrats:<BR>Dr. Franz
Scherer<BR><BR>Handelsregister:<BR>HRB 240708
Mannheim<BR><BR>_______________________________________________<BR>Ocfs2-users
mailing list<BR></FONT><A href="mailto:Ocfs2-users@oss.oracle.com"><FONT
face=Arial size=2>Ocfs2-users@oss.oracle.com</FONT></A><BR><A
href="http://oss.oracle.com/mailman/listinfo/ocfs2-users"><FONT face=Arial
size=2>http://oss.oracle.com/mailman/listinfo/ocfs2-users</FONT></A><BR></DIV></BLOCKQUOTE></BODY></HTML>