On Wed, Apr 06, 2011 at 10:26:24AM -0600, Reid, Mike wrote: > Lars, > > Thank you for your comments. I did confirm I was running 8.3.8.1, and I have > even upgraded to 8.3.10 but am still experiencing the same I/O lock issue. I > definitely agree with you, DRBD is behaving exactly as instructed, being > properly fenced, etc. > > I am quite new to DRBD (and OCFS2), learning a lot as I go. To your > question regarding copy/paste, yes, the configuration used was > culminated from a series of different tutorials, plus personal trial > and error related to this project. I have tried many variations of the > DRBD config (including resource-and-stonith)
> but have not actually set up a functioning STONITH yet, And that's why your ocfs2 does not unblock. It waits for confirmation of a STONITH operation. > hence the > "resource-only". The Linbit > docs have been an amazing resource. > > Yes, I realize that a Secondary-node is not indicative of it's > data/synch state. The options I am testing here were referenced from > this page: > > > > http://www.drbd.org/users-guide/s-ocfs2-create-resource.html > > http://www.drbd.org/users-guide/s-configure-split-brain-behavior.html#s-automatic-split-brain-recovery-configuration > > > > > When you say "You do configure automatic data loss here", are you > suggesting that I am instructing DRBD survivor to perform a full > re-synch to it's peer? Nothing to do with full sync. Should usually be a bitmap based resync. But it may be a sync in an "unexpected" direction. > If so, that would make sense since I believe > this behavior was something I experienced prior to getting fencing > fully established. In my hard-boot testing, I did once notice the > "victim" was completely resynching, which sounds related to > "after-sb-1pri discard-secondary". > > DRBD aside, have you used OCFS2? I'm failing to realize why if DRBD is > fencing it's peer that OCFS2 remains in a locked-state, unable to run > standalone? To me, this issue does not seem related to DRBD or Pacemaker, but > rather a lower-level requirement of OCFS2 (DLM?), etc. > > To date, the ONLY way I can restore I/O to the remaining node is to bring the > other node back online, which unfortunately won't work in our Production > environment. On a separate ML, someone made a suggestion that "qdisk" might > be required to make this work, and while I have tried "qdisk", my high-level > research leads me to believe that is a legacy approach, not an option with > Pacemaker. Is that correct? > _______________________________________________ > 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. _______________________________________________ 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
