<br> Well, I stand corrected, and do think he has a point. OCFS2 is heavilly tested on Oracle RAC related scenarios, large files, high I/O rates, etc. On other scenarios, dealing with ACLs, and multiple user ids, it might not be so throrougly tested. But I do see a large effort to resolve any issues that are reported.<br><br> Also there is the point that it is designed for Oracle database use. So the fencing and reboots are intentional, and they happen fast. All nodes in Oracle RAC freeze when one of the nodes is unreachable, either by SAN or network failures, this is inevitable due to the architecture of the database itself, so it is highly desirable that the misbehaving node go down fast, so that the other nodes can start crash recovery of the failed node, during which the database is still hung, since the crashed node memory structures are lost and need to be recovered from the redo and rollback segments.
<br><br> One thing that I think could be improved is that there is no communication between the O2CB and CRS, so if the timeouts are not setup correctly, one can have a situation where O2CB resolves to fence one node, and CRS fences the other. This seems to not happen with vendor clusterware, that always have to be integrated with CRS to be supported with Oracle RAC.<br><br> Other thing that would be interesting, if technically feasible, would be to have a option for OCFS2 behave more like NFS, and instead of rebooting, fence all I/O to the filesystems on the evicted node, waiting to see if it can rejoin the cluster. When this situation occurs the fenced node would need to consider all the blocks on the buffer cache as invalid, so that other nodes could modify them safely. Not sure how filesystem locks could be handled.<br><br>Regards,<br>Luis<br><br><b><i>Sunil Mushran <Sunil.Mushran@oracle.com></i></b> wrote:<blockquote
class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> Randy Ramsdell wrote:<br>> I am not taking sides but I think Alexei's postings are a positive <br>> contribution to this project and more of a contribution than the <br>> lurkers who write nothing to the list. His feedback does have merit <br>> and should be considered valuable although it is critical of ocfs2. <br>> We, although I strongly disagreed, have stopped using ocfs2 and we <br>> WERE using it in a production environment.<br>><br>The so-called lurkers file bugs, validate patches. That helps everybody.<br><br>His feedback is useless. Ranting about the core design does not help<br>anyone. Dreaming up possible bugs, without actually looking for them,<br>is useless.<br><br>When you encounter a bug, file a bugzilla with as much relevant<br>information as possible. If you do that, we can fix the bug and everyone<br>benefits. Sending emails like a
broken record is not a positive <br>contribution.<br><br>BTW, I hear great things about Vista.<br><br>_______________________________________________<br>Ocfs2-users mailing list<br>Ocfs2-users@oss.oracle.com<br>http://oss.oracle.com/mailman/listinfo/ocfs2-users<br></blockquote><br><p> 
<hr size=1>Need a vacation? <a href="http://us.rd.yahoo.com/evt=48256/*http://travel.yahoo.com/;_ylc=X3oDMTFhN2hucjlpBF9TAzk3NDA3NTg5BHBvcwM1BHNlYwNncm91cHMEc2xrA2VtYWlsLW5jbQ--">Get great deals
to amazing places </a>on Yahoo! Travel.