<div dir="ltr">I&#39;m configuring a two node setup with drbd 9.0.20-1 on CentOS 7 (3.10.0-957.1.3.el7.x86_64) with a single resource backed by an SSDs.  I&#39;ve explicitly enabled auto-promote in my resource configuration to use this feature.<div><br></div><div>The drbd device is being used in a single-primary configuration as a zpool SLOG device.  The zpool is only ever imported on one node at a time and the import is successful during cluster failover events between nodes.  I confirmed through zdb that the zpool includes the configured drbd device path.</div><div><br></div><div>My concern is that the drbdadm status output shows the Role of the drbd resource as &quot;Secondary&quot; on both sides.  The documentations reads that the drbd resource will be auto promoted to primary when it is opened for writing.</div><div><br></div><div>drbdadm status<br>r0 role:Secondary<br>  disk:UpToDate<br>  dccdx0 role:Secondary<br>    peer-disk:UpToDate<br></div><div><br></div><div>My device should be opened for writing when the zpool is imported.  I&#39;ve even tested writing to the pool with &quot;dd oflag=sync&quot; to force sync writes to the SLOG which is the drbd resource.  The drbd device never changes the reported state but it appears to be writable.</div><div><br></div><div>Have I misconfigured my drbd resource for an auto-promote configuration and/or is my use case to obscure for auto-promote to detect the device is being written to when used in a zpool?</div><div><br></div><div>=========== /etc/drbd.d/r0.res</div><div>resource r0 {<br>    disk &quot;/dev/disk/by-path/pci-0000:18:00.0-scsi-0:0:2:0-part1&quot;;<br>    meta-disk internal;<br>    device minor 0;<br><br>    on dccdx0 {<br>        address <a href="http://192.0.2.10:7000">192.0.2.10:7000</a>;<br>    }<br><br>    on dccdx1 {<br>        address <a href="http://192.0.2.20:7000">192.0.2.20:7000</a>;<br>    }<br><br>    disk {<br>        read-balancing when-congested-remote;<br>        no-disk-flushes;<br>        no-md-flushes;<br>        # al-updates no; # turn off al-tracking; requires full sync on crash<br>        c-fill-target 4M;<br>        resync-rate 500M;<br>        c-max-rate 1000M;<br>        c-min-rate 700M;<br>    }<br><br>    net {<br>        sndbuf-size 10M;<br>        rcvbuf-size 10M;<br>        max-buffers 20000;<br>        fencing resource-and-stonith;<br>    }<br>}<br></div><div><br></div><div>-Doug</div></div>