<div>Hello!</div><div> </div><div>I have configuration of resource:</div><div> </div><div>[root@pan ~]# drbdadm dump A</div><div># resource A on pan: not ignored, not stacked</div><div># defined at /etc/drbd.d/A.res:1</div><div>resource A {</div><div>    floating        ipv4 172.16.20.50:11001 {</div><div>        node-id 0;</div><div>        device          /dev/drbd_A minor 1;</div><div>        disk            /dev/A;</div><div>        meta-disk        /dev/mapper/META2_vg-A;</div><div>    }</div><div>    floating        ipv4 172.16.20.71:11001 {</div><div>        node-id 1;</div><div>        device          /dev/drbd_A minor 1;</div><div>        disk            /dev/A;</div><div>        meta-disk        /dev/mapper/META_vg-A;</div><div>    }</div><div>    net {</div><div>        protocol          C;</div><div>        verify-alg      sha256;</div><div>    }</div><div>}</div><div> </div><div>If node 172.16.20.71 is primary and connection between them successfully established,</div><div>from time to time when I call `drbdadm down A`, I get an error that access to UpToDate data is need. Here's some log:</div><div> </div><div><div>Sep  7 17:35:06 666 kernel: [881937.955928] drbd A: role( Primary -&gt; Secondary )</div><div>Sep  7 17:35:06 666 kernel: [881937.980564] drbd A: Preparing cluster-wide state change 2246176250 (1-&gt;0 496/16)</div><div>Sep  7 17:35:06 666 kernel: [881937.982451] drbd A: State change 2246176250: primary_nodes=0, weak_nodes=0</div><div>Sep  7 17:35:06 666 kernel: [881937.982453] drbd A 172.16.20.50:11001: Cluster is now split</div><div>Sep  7 17:35:06 666 kernel: [881937.982454] drbd A: Committing cluster-wide state change 2246176250 (2ms)</div><div>Sep  7 17:35:06 666 kernel: [881937.982510] drbd A 172.16.20.50:11001: conn( Connected -&gt; Disconnecting ) peer( Secondary -&gt; Unknown )</div><div>Sep  7 17:35:06 666 kernel: [881937.982512] drbd A/0 drbd1 172.16.20.50:11001: pdsk( UpToDate -&gt; DUnknown ) repl( Established -&gt; Off )</div><div>Sep  7 17:35:06 666 kernel: [881937.982544] drbd A 172.16.20.50:11001: ack_receiver terminated</div><div>Sep  7 17:35:06 666 kernel: [881937.982545] drbd A 172.16.20.50:11001: Terminating ack_recv thread</div><div>Sep  7 17:35:06 666 kernel: [881937.986060] drbd A 172.16.20.50:11001: Connection closed</div><div>Sep  7 17:35:06 666 kernel: [881937.986086] drbd A 172.16.20.50:11001: conn( Disconnecting -&gt; StandAlone )</div><div>Sep  7 17:35:06 666 kernel: [881937.986095] drbd A 172.16.20.50:11001: Terminating receiver thread</div><div>Sep  7 17:35:06 666 kernel: [881937.986134] drbd A 172.16.20.50:11001: Terminating sender thread</div><div>Sep  7 17:35:06 666 kernel: [881937.986173] drbd A: State change failed: Need access to UpToDate data</div><div>Sep  7 17:35:06 666 kernel: [881937.986176] drbd A/0 drbd1: Failed: disk( UpToDate -&gt; Detaching )</div><div> </div><div>If I call it next time, operation is usually success.</div><div>If I set resource role to secondary before go down, it is more successful than calling `down` from primary resource.</div><div> </div><div>Questions: What is absolutely correct way to down a resource without such error?</div><div>Is there some special sequence of commands required?</div><div>What this error does ever mean?<br /><br />Information about DRBD:</div><div><div>[root@pan ~]# drbdadm --version</div><div>DRBDADM_BUILDTAG=GIT-hash:\ 98b6340c328b763a11c6fb63a6dc340722621ac2\ build\ by\ root@pan\,\ 2017-08-24\ 12:48:41</div><div>DRBDADM_API_VERSION=2</div><div>DRBD_KERNEL_VERSION_CODE=0x090008</div><div>DRBD_KERNEL_VERSION=9.0.8</div><div>DRBDADM_VERSION_CODE=0x090000</div><div>DRBDADM_VERSION=9.0.0</div></div></div>