Re: 9.3.4: resync after a crashed Primary misses blocks (silent divergence) if that node was promoted in place after being Secondary under another Primary

[Dominic <dominic@let2.com>]

Hi Phil,

Thank you for the quick and clear answer.

I re-ran our sequence on current master in the same two VMs:
git 0192e7af3 ("Merge drbd-9.2/793f90dff53c ..."), which contains
39d0a42c51a1 and cabad431fc02, built with "make" against
7.0.0-38-generic and installed in place of the 9.3.4 dkms module on
both nodes. drbd-utils is unchanged (9.35.0), and so is the
configuration (2 volumes, max-peers left at the default).

Results, with the same steps as in my report:

- Failing case (B Primary, write, demote, then in-place promotion of
  A), twice: the log still shows "Disabling local AL-updates
  (optimization)" while B is Primary. After A's crash and attach, A
  resyncs 28672 KB [7168 bits set] on volume 0 (9.3.4: 3072 bits), and
  the backing devices match on both volumes. Both runs passed.
- Control without the B Primary step: 6144 bits, match.

So the fix covers our exact sequence. On 9.3.4 it failed 3 times out
of 3; on master it passed 2 out of 2, plus the control.

For production we will keep promoting only after a fresh attach, and
move to the first release that carries the fix.

Best regards,
Dominic