01.11.2012 02:47, Andrew Beekhof wrote: ... >> >> One remark about that - it requires that gfs2 communicates with dlm in >> the kernel space - so gfs_controld is not longer required. I think >> Fedora 17 is the first version with that feature. And it is definitely >> not available for EL6 (centos6 which I use). >> >> But I have preliminary success running GFS2 with corosync2 and pacemaker >> 1.1.8 on EL6. dlm4 runs just fine as is (although it misses some >> featured on EL6 because of kernel). And it still includes (not >> documented) option enable_fscontrol, so user-space communication with fs >> control daemons is supported. Even it that feature will be removed >> upstream, it can be easily returned back - just several lines of code. >> And I ported gfs_controld from cman to corosync2 (patch is very dirty >> yet, made with scissors and needle, just a proof-of-concept that it even >> can work). Some features are unsupported (f.e. nodir) and will not be >> implemented by me. > > I'm impressed. What was the motivation though? You really really > don't like CMAN? :-)
Why should I like software which is going to die? ;) I believe that how things are done currently (third case from your list) fully reflect my "perfectionistic" needs. I had many problems with cman+pacemaker in a past. Most critical is that pacemaker and dlm_controld react differently when node reappears back very soon after if was lost (because pacemaker uses totem ? directly for membership, but dlm uses CPG). Pacemaker accepts that, but controld freezes lockspaces, waiting for fencing. But fencing is never done because nobody handles "node lost" CPG event. dlm does start fencing for "process lost", but not for "node lost". _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org