Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 2008-09-13T03:01:11, Lars Marowsky-Bree <lmb at suse.de> wrote: Ahh, it all just clicked into place! A slave always considers itself "outdated", until this flag is cleared. (The flag is persistent in the meta-data.) While outdated, it refuses to promote. The "outdated" flag is cleared either by receiving a "stop" notification for the peer (which pacemaker delivers), or that the peer has been demoted (which we can either deliver using pacemaker, but of course drbd knows via its internal protocol). A primary, on loss of connection to the peer, freezes IO (sets the outdated flag?). It invokes a call-out "crm_resource -F" _for the peer_, which causes pacemaker to stop the peer. (Stopping the peer w/o connection means that the peer will save its outdated flag to disk, and be unable to promote.) The primary will then receive a "stop" notification for the peer (either because it was indeed stopped, or fenced), and then unfreezes (clears the outdated flag again?). I think that covers everything for primary/secondary. I'm not perfectly sure how to handle primary/primary; I believe the second paragraph above handles it, but it would cause both sides to stop; drbd might need some internal mechanism to pre-determine which side will do that on primary/primary; it doesn't really matter which, I think - maybe the lowest id? Regards, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde