<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 2021-08-10 2:11 a.m., Eddie Chapman
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:429aec05-4cd4-917d-cf23-c65d7adbb099@ehuk.net">On
      10/08/2021 00:01, Digimer wrote:
      <br>
      <blockquote type="cite">On 2021-08-05 5:53 p.m., Janusz Jaskiewicz
        wrote:
        <br>
        <blockquote type="cite">Hello.
          <br>
          <br>
          I'm experimenting a bit with DRBD in a cluster managed by
          Pacemaker.
          <br>
          It's a two node, active-passive cluster and the service that
          I'm trying to put in the cluster writes to the file system.
          <br>
          The service manages many files, it appends to some of them and
          increments the single integer value in others.
          <br>
          <br>
          I'm observing surprising behaviour and I would like to ask you
          if what I see is expected or not (I think not).
          <br>
          <br>
          I'm using protocol C, but still I see some delay in the files
          that are being replicated to the secondary server.
          <br>
          For the files that increment the integer I see a difference
          which corresponds roughly to 1 second of traffic.
          <br>
          <br>
          I'm really surprised to see this, as protocol C should
          guarantee synchronous replication.
          <br>
          I'd rather expect some delay in processing (potentially slower
          disk writes due to the network replication).
          <br>
          <br>
          The way I'm testing it:
          <br>
          The service runs on primary and writes to DRBD drive,
          secondary connected and "UpToDate".
          <br>
          I kill the service abruptly (kill -9) and then take down the
          network interface between primary and secondary (kill and
          ifdown commands in the script so executed quite promptly one
          after the other).
          <br>
          Then I mount the DRBD drive on both nodes and check the
          difference in the files with incrementing integer.
          <br>
          <br>
          I would appreciate any help or pointers on how to fix this.
          <br>
          But first of all I would like to confirm that this behaviour
          is not expected.
          <br>
          <br>
          Also if it is expected/allowed, how can I decrease the impact?
          <br>
        </blockquote>
      </blockquote>
      <br>
      <blockquote type="cite">What filesystem are you using? Is it
        cluster / multi-node aware?
        <br>
      </blockquote>
      <br>
      The filesystem may be relevant in that filesystems can behave in
      ways one might not expect, depending on how they are tuned, so
      would be good to know what the fs is and what mount options are
      being used. However, the filesystem certainly does not need to be
      aware that the underlying block device is drbd or a cluster of any
      kind. A drbd device should look like a regular block device and
      there is no need to treat it like anything else.
      <br>
      <br>
      I would like to know the kernel and drbd versions, if these are
      old enough then expecting things to "work" in a sane fashion might
      not be a reasonable expectation :-)
      <br>
    </blockquote>
    <p>The reason I asked is because all DRBD does is replicate the
      blocks. It doesn't (and can't) handle locks to avoid corruption,
      update file lists, etc. If you've mounted, say, xfs or ext4 on
      both nodes, then it's a surprise it updates at all, never mind
      being a few seconds delayed. If you're using a proper cluster FS
      like GFS2 or ocfs, then we may want to investigate those.</p>
    <pre class="moz-signature" cols="72">-- 
Digimer
Papers and Projects: <a class="moz-txt-link-freetext" href="https://alteeve.com/w/">https://alteeve.com/w/</a>
"I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." - Stephen Jay Gould</pre>
  </body>
</html>